Re: Container type classes

I'm not sure if this is related but the package Map-Classes provides about 50 functions on around a dozen key/value like datatypes e.g. Arrays, Maps, Sets (value is ()) etc. Even ByteStrings are included (Int

RE: Container type classes

Thanks again Iavor, Despite the type inference issue, and the fact that this requires a separate type class, this is the best solution I've seen so far. Cheers, Andrey -Original Message- From: Iavor Diatchki [mailto:iavor.diatc...@gmail.com] Sent: 30 May 2019 23:16 To: Andrey Mokhov

Re: Container type classes

Yeah, there is really no relation between the two parameters of `Fun`, so you'd have to specify the intermediate type manually. For example: add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s add3 = colMap @s (+1) . colMap (+2) I wouldn't say that it's a particularly convenient interface to

RE: Container type classes

Many thanks Iavor, This looks very promising! I played with your encoding a little, but quickly came across type inference issues. The following doesn't compile: add3 :: (Fun s s, Elem s ~ Int) => s -> s add3 = colMap (+1) . colMap (+2) I'm getting: * Could not deduce: Elem a0 ~ Int

Re: Container type classes

I was talking in general about why you don't find instances of Monad, etc. for Set or Map which require an additional constraint on the key. On Thu, May 30, 2019 at 5:36 PM Andrey Mokhov wrote: > Hi Brandon, > > > > Could you show the code? > > > > I have no idea how indexed monads could

Re: Container type classes

This is how you could define `map`. This is just for fun, and to discuss Haskell idioms---I am not suggesting we should do it. Of course, it might be a bit more general than what you'd like---for example it allows defining instances like `Fun IntSet (Set Int)` that, perhaps?, you'd like to

RE: Container type classes

Hi Brandon, Could you show the code? I have no idea how indexed monads could possibly be related here. All I want is to have a type class that unifies these two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet

Re: Container type classes

They can, with more work. You want indexed monads, so you can describe types that have e.g. an ordering constraint as well as the Monad constraint. On Thu, May 30, 2019 at 5:26 PM Andrey Mokhov wrote: > Hi Artem, > > > > Thanks for the pointer, but this doesn’t seem to be a solution to my >

RE: Container type classes

Hi Artem, Thanks for the pointer, but this doesn’t seem to be a solution to my challenge: they simply give up on overloading `map` for both Set and IntSet. As a result, we can’t write polymorphic functions over Set and IntSet if they involve any mapping. I looked at the prototype by Andreas

Re: Container type classes

Hi Andrey, FWIW, mono-traversable (http://hackage.haskell.org/package/mono-traversable) suggests decoupling IsSet and Funtor-like. In a nutshell, they define the IsSet class (in Data.Containers) with typical set operations like member and singleton, union and intersection. And then they tackle a

RE: Container type classes

> If you care about performance then explicit dictionary passing is > going to be worse than using type classes. Of course! But explicit dictionary passing works great for tests: the code size is reduced from O(#modules * #tests) when using the module system to O(#modules + #tests) when using

Re: Container type classes

If you care about performance then explicit dictionary passing is going to be worse than using type classes. At that point though, what do you gain from using the module system as you are just going to pass the same dictionaries into every function and never change them. So, for me, keep using

RE: Container type classes

Hi all, I tried to use type classes for unifying APIs of several similar data structures and it didn't work well. (In my case I was working with graphs, instead of sets or maps.) First, you rarely want to be polymorphic over the set representation, because you care about performance. You

Re: Fwd: [hadrian/windows] build broken

Shayne Fletcher via ghc-devs writes: > On Thu, May 30, 2019 at 8:32 AM Alp Mestanogullari > wrote: > >> Heh, it landed less than an hour ago. >> >> If the error persists, you'll probably want to do a clean build, by >> removing at the very least _build/stage1, even though I'd say it can't hurt

Re: Fwd: [hadrian/windows] build broken

On Thu, May 30, 2019 at 9:18 AM Alp Mestanogullari wrote: > I haven't (yet) worked on making an OS X job for Hadrian. I brought back > the Windows/Hadrian CI job with that fix, but then tried running the > testsuite, which didn't go well, see: > >

Re: Fwd: [hadrian/windows] build broken

I haven't (yet) worked on making an OS X job for Hadrian. I brought back the Windows/Hadrian CI job with that fix, but then tried running the testsuite, which didn't go well, see: https://gitlab.haskell.org/ghc/ghc/merge_requests/1035 https://gitlab.haskell.org/alp/ghc/-/jobs/87467 This

Re: Fwd: [hadrian/windows] build broken

On Thu, May 30, 2019 at 8:32 AM Alp Mestanogullari wrote: > Heh, it landed less than an hour ago. > > If the error persists, you'll probably want to do a clean build, by > removing at the very least _build/stage1, even though I'd say it can't hurt > to remove _build altogether. Along with that

Re: Fwd: [hadrian/windows] build broken

Heh, it landed less than an hour ago. If the error persists, you'll probably want to do a clean build, by removing at the very least _build/stage1, even though I'd say it can't hurt to remove _build altogether. Along with that patch, I also brought back the Windows CI job and the error did

Re: Fwd: [hadrian/windows] build broken

On Thu, May 30, 2019 at 6:55 AM Shayne Fletcher wrote: > Hi Alp, > > On Fri, May 24, 2019 at 11:34 AM Shayne Fletcher > wrote: > >> >> On Fri, May 24, 2019 at 7:33 AM Alp Mestanogullari >> wrote: >> >>> Hello Shayne, >>> >>> David and I figured out the cause of that problem, I am working on a

Re: Fwd: [hadrian/windows] build broken

Hi Alp, On Fri, May 24, 2019 at 11:34 AM Shayne Fletcher wrote: > > On Fri, May 24, 2019 at 7:33 AM Alp Mestanogullari > wrote: > >> Hello Shayne, >> >> David and I figured out the cause of that problem, I am working on a >> patch, will put it up as a (WIP) MR as soon as it's ready. >> >> >