May 2019 - ghc-devs - Haskell.org

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

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.diatchki@gmail.com] Sent: 30 May 2019 23:16 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: Brandon Allbery <allbery.b(a)gmail.com>; Andreas Klebinger <klebinger.andreas(a)gmx.at>; ghc-devs(a)haskell.org Subject: 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 work with, unless you are working in a setting where most of the containers have known types. On Thu, May 30, 2019 at 2:58 PM Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> wrote: > > 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 > from the context: (Fun s s, Elem s ~ Int) > bound by the type signature for: > add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s > Expected type: Elem a0 -> Elem s > Actual type: Int -> Int > The type variable `a0' is ambiguous > > Fun s s is supposed to say that the intermediate type is `s` too, but I guess this is not how type class resolution works. > > Cheers, > Andrey > > -----Original Message----- > From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com] > Sent: 30 May 2019 22:38 > To: Brandon Allbery <allbery.b(a)gmail.com> > Cc: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Andreas Klebinger <klebinger.andreas(a)gmx.at>; ghc-devs(a)haskell.org > Subject: 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 disallow: > > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} > > import Data.Set (Set) > import qualified Data.Set as Set > import Data.IntSet (IntSet) > import qualified Data.IntSet as ISet > > class Col t where > type Elem t > -- ... As in Andreas's example > > class (Col a, Col b) => Fun a b where > colMap :: (Elem a -> Elem b) -> a -> b > > instance Col (Set a) where > type Elem (Set a) = a > > instance Col IntSet where > type Elem IntSet = Int > > instance Fun IntSet IntSet where > colMap = ISet.map > > instance Ord b => Fun (Set a) (Set b) where > colMap = Set.map > > On Thu, May 30, 2019 at 2:32 PM Brandon Allbery <allbery.b(a)gmail.com> wrote: > > > > 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 <andrey.mokhov(a)newcastle.ac.uk> wrote: > >> > >> 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 Klebinger, and it doesn’t include the method `setMap` either. > >> > >> > >> > >> Perhaps, Haskell’s type classes just can’t cope with this problem. > >> > >> > >> > >> *ducks for cover* > >> > >> > >> > >> Cheers, > >> > >> Andrey > >> > >> > >> > >> From: Artem Pelenitsyn [mailto:a.pelenitsyn@gmail.com] > >> Sent: 30 May 2019 20:56 > >> To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> > >> Cc: ghc-devs(a)haskell.org; Andreas Klebinger <klebinger.andreas(a)gmx.at> > >> Subject: 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 (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): > >> > >> > >> > >> class MonoFunctor mono where > >> omap :: (Element mono -> Element mono) -> mono -> mono > >> > >> > >> > >> And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. > >> > >> > >> > >> -- > >> > >> Best wishes, > >> > >> Artem > >> > >> > >> > >> On Thu, 30 May 2019 at 20:11, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> wrote: > >> > >> 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 really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like > >> > >> memberInsertProperty x set = (member x (insert x set) == True) > >> > >> and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! > >> > >> However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: > >> > >> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > >> > >> where `member` and `insert` come from the SetAPI record via RecordWildCards. > >> > >> Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: > >> > >> singleton :: a -> Set a > >> map :: Ord b => (a -> b) -> Set a -> Set b > >> > >> singleton :: Int -> IntSet > >> map :: (Int -> Int) -> IntSet -> IntSet > >> > >> Could anyone please enlighten me about the right way to abstract over this using type classes? > >> > >> I tried a few approaches, for example: > >> > >> class IsSet s where > >> type Elem s > >> singleton :: Elem s -> s > >> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > >> > >> Looks nice, but I can't define the IntSet instance: > >> > >> instance IsSet IntSet where > >> type Elem IntSet = Int > >> singleton = IntSet.singleton > >> map = IntSet.map > >> > >> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. > >> > >> ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. > >> > >> Cheers, > >> Andrey > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs(a)haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > >> _______________________________________________ > >> ghc-devs mailing list > >> ghc-devs(a)haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > > > > -- > > brandon s allbery kf8nh > > allbery.b(a)gmail.com > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

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 from the context: (Fun s s, Elem s ~ Int) bound by the type signature for: add3 :: forall s. (Fun s s, Elem s ~ Int) => s -> s Expected type: Elem a0 -> Elem s Actual type: Int -> Int The type variable `a0' is ambiguous Fun s s is supposed to say that the intermediate type is `s` too, but I guess this is not how type class resolution works. Cheers, Andrey -----Original Message----- From: Iavor Diatchki [mailto:iavor.diatchki@gmail.com] Sent: 30 May 2019 22:38 To: Brandon Allbery <allbery.b(a)gmail.com> Cc: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Andreas Klebinger <klebinger.andreas(a)gmx.at>; ghc-devs(a)haskell.org Subject: 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 disallow: {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} import Data.Set (Set) import qualified Data.Set as Set import Data.IntSet (IntSet) import qualified Data.IntSet as ISet class Col t where type Elem t -- ... As in Andreas's example class (Col a, Col b) => Fun a b where colMap :: (Elem a -> Elem b) -> a -> b instance Col (Set a) where type Elem (Set a) = a instance Col IntSet where type Elem IntSet = Int instance Fun IntSet IntSet where colMap = ISet.map instance Ord b => Fun (Set a) (Set b) where colMap = Set.map On Thu, May 30, 2019 at 2:32 PM Brandon Allbery <allbery.b(a)gmail.com> wrote: > > 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 <andrey.mokhov(a)newcastle.ac.uk> wrote: >> >> 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 Klebinger, and it doesn’t include the method `setMap` either. >> >> >> >> Perhaps, Haskell’s type classes just can’t cope with this problem. >> >> >> >> *ducks for cover* >> >> >> >> Cheers, >> >> Andrey >> >> >> >> From: Artem Pelenitsyn [mailto:a.pelenitsyn@gmail.com] >> Sent: 30 May 2019 20:56 >> To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> >> Cc: ghc-devs(a)haskell.org; Andreas Klebinger <klebinger.andreas(a)gmx.at> >> Subject: 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 (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): >> >> >> >> class MonoFunctor mono where >> omap :: (Element mono -> Element mono) -> mono -> mono >> >> >> >> And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. >> >> >> >> -- >> >> Best wishes, >> >> Artem >> >> >> >> On Thu, 30 May 2019 at 20:11, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> wrote: >> >> 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 really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like >> >> memberInsertProperty x set = (member x (insert x set) == True) >> >> and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! >> >> However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: >> >> memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) >> >> where `member` and `insert` come from the SetAPI record via RecordWildCards. >> >> Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: >> >> singleton :: a -> Set a >> map :: Ord b => (a -> b) -> Set a -> Set b >> >> singleton :: Int -> IntSet >> map :: (Int -> Int) -> IntSet -> IntSet >> >> Could anyone please enlighten me about the right way to abstract over this using type classes? >> >> I tried a few approaches, for example: >> >> class IsSet s where >> type Elem s >> singleton :: Elem s -> s >> map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t >> >> Looks nice, but I can't define the IntSet instance: >> >> instance IsSet IntSet where >> type Elem IntSet = Int >> singleton = IntSet.singleton >> map = IntSet.map >> >> This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. >> >> ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. >> >> Cheers, >> Andrey >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b(a)gmail.com > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

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 -> IntSet Cheers, Andrey From: Brandon Allbery [mailto:allbery.b@gmail.com] Sent: 30 May 2019 22:32 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: Artem Pelenitsyn <a.pelenitsyn(a)gmail.com>; Andreas Klebinger <klebinger.andreas(a)gmx.at>; ghc-devs(a)haskell.org Subject: 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 <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: 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 Klebinger, and it doesn’t include the method `setMap` either. Perhaps, Haskell’s type classes just can’t cope with this problem. *ducks for cover* Cheers, Andrey From: Artem Pelenitsyn [mailto:a.pelenitsyn@gmail.com<mailto:a.pelenitsyn@gmail.com>] Sent: 30 May 2019 20:56 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> Cc: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>; Andreas Klebinger <klebinger.andreas(a)gmx.at<mailto:klebinger.andreas@gmx.at>> Subject: 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 (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. -- Best wishes, Artem On Thu, 30 May 2019 at 20:11, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: 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 really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- brandon s allbery kf8nh allbery.b(a)gmail.com<mailto:allbery.b@gmail.com>

2 1

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

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 Klebinger, and it doesn’t include the method `setMap` either. Perhaps, Haskell’s type classes just can’t cope with this problem. *ducks for cover* Cheers, Andrey From: Artem Pelenitsyn [mailto:a.pelenitsyn@gmail.com] Sent: 30 May 2019 20:56 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: ghc-devs(a)haskell.org; Andreas Klebinger <klebinger.andreas(a)gmx.at> Subject: 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 (seemingly) independent problem of mapping monomorphic containers (like IntSet, ByteString, etc.) with a separate class MonoFunctor (in Data.MonoTraversable): class MonoFunctor mono where omap :: (Element mono -> Element mono) -> mono -> mono And gazillion of instances for both polymorphic containers with a fixed type parameter and monomorphic ones. -- Best wishes, Artem On Thu, 30 May 2019 at 20:11, Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: 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 really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 2

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

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 really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like memberInsertProperty x set = (member x (insert x set) == True) and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) where `member` and `insert` come from the SetAPI record via RecordWildCards. Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: singleton :: a -> Set a map :: Ord b => (a -> b) -> Set a -> Set b singleton :: Int -> IntSet map :: (Int -> Int) -> IntSet -> IntSet Could anyone please enlighten me about the right way to abstract over this using type classes? I tried a few approaches, for example: class IsSet s where type Elem s singleton :: Elem s -> s map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t Looks nice, but I can't define the IntSet instance: instance IsSet IntSet where type Elem IntSet = Int singleton = IntSet.singleton map = IntSet.map This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. Cheers, Andrey

3 2

RE: Container type classes
by Andrey Mokhov 30 May '19

30 May '19

> 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 dictionaries. For example, in the algebraic-graphs library, I have 500+ generic tests and around 10 modules. I don't want to write 5000 tests! Here is an example generic test which uses explicit dictionary passing: https://github.com/snowleopard/alga/blob/master/test/Algebra/Graph/Test/Gen…. I don't think it would be possible to reuse this test for different graph data types by using the module system instead of dictionaries. (Perhaps, Backpack could help? I don't know it very well.) Cheers, Andrey -----Original Message----- From: Matthew Pickering [mailto:matthewtpickering@gmail.com] Sent: 30 May 2019 18:26 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: ghc-devs(a)haskell.org; Andreas Klebinger <klebinger.andreas(a)gmx.at> Subject: 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 modules but make the APIs of each module more consistent if you think it's worthwhile. On Thu, May 30, 2019 at 6:11 PM Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> wrote: > > 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 really want to use that Very.Special.Set.insert because it has the right performance characteristics for your task at hand. I found only *one* use-case for writing polymorphic functions operating on something like IsSet: the testsuite. Of course, it is very nice to write a single property test like > > memberInsertProperty x set = (member x (insert x set) == True) > > and then use it for testing all set data structures that implement `member` and `insert`. Here you don't care about performance, only about correctness! > > However, this approach leads to problems with type inference, confusing error messages, and complexity. I found that it is much nicer to use explicit dictionary passing and write something like this instead: > > memberInsertProperty SetAPI{..} x set = (member x (insert x set) == True) > > where `member` and `insert` come from the SetAPI record via RecordWildCards. > > Finally, I'm not even sure how to create a type class covering Set and IntSet with the following two methods: > > singleton :: a -> Set a > map :: Ord b => (a -> b) -> Set a -> Set b > > singleton :: Int -> IntSet > map :: (Int -> Int) -> IntSet -> IntSet > > Could anyone please enlighten me about the right way to abstract over this using type classes? > > I tried a few approaches, for example: > > class IsSet s where > type Elem s > singleton :: Elem s -> s > map :: Ord (Elem t) => (Elem s -> Elem t) -> s -> t > > Looks nice, but I can't define the IntSet instance: > > instance IsSet IntSet where > type Elem IntSet = Int > singleton = IntSet.singleton > map = IntSet.map > > This fails with: Couldn't match type `t' with `IntSet' -- and indeed, how do I tell the compiler that in the IntSet case s ~ t in the map signature? Shall I add more associated types, or "associated constraints" using ConstraintKinds? I tried and failed, at various stages, repeatedly. > > ...And then you discover that there is Set.cartesianProduct :: Set a -> Set b -> Set (a, b), but no equivalent in IntSet and things get even more grim. > > Cheers, > Andrey > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

[hadrian/windows] build broken
by Shayne Fletcher 30 May '19

30 May '19

Windows builds with hadrian are currently failing with "file does not exist and no build rule available" `_build/stage1/libffi/build/inst/bin/libffi-6.dll`. Anybody have an ideas on how to overcome that? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

4 17

Two weeks left for Haskell Exchange talk proposals
by Spiwack, Arnaud 29 May '19

29 May '19

Dear all, Only two weeks remain before the end of the Haskell eXchange call-for-paper (11th of june). Send your proposals! This year's keynote speaker will be Elise Huard, Gabriele Keller, Simon Peyton Jones, and Philip Wadler. Find the full CFP and submit your proposal here: https://docs.google.com/forms/d/e/1FAIpQLSeJgeTqAdYLBlRcO9PDzI3yrR22CqzhInH…

1 0

RE: Clean build fails with make
by Simon Peyton Jones 29 May '19

29 May '19

| Anyways the workaround, other than a big `git clean -fdx`, is a removing | these three files | | * includes/dist/build/settings, | * lib/settings, | * settings | | Then make will regenerate them. Excellent, that works. | I would be happy to change the cleaning | stuff to actually fix the issue, but I am not sure how. It may not matter. We don't want to spend lots of time on the old build system. Is this a once-only thing? I.e. once done will never happen again? Or might it happen repeatedly? Simon | -----Original Message----- | From: John Ericson <git(a)johnericson.me> | Sent: 28 May 2019 23:33 | To: Ben Gamari <ben(a)well-typed.com> | Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; GHC developers <ghc- | devs(a)haskell.org> | Subject: Re: Clean build fails with make | | This is the same issue as before; and I don't know how the cleaning works. | The good thing is that I think I am done adding things to that. (Perhaps | some should be removed, but that won't cause these issues.) | | Anyways the workaround, other than a big `git clean -fdx`, is a removing | these three files | | * includes/dist/build/settings, | * lib/settings, | * settings | | Then make will regenerate them. I would be happy to change the cleaning | stuff to actually fix the issue, but I am not sure how. | | Sorry for more disruption, | | John | | On Tue, May 28, 2019, at 5:56 PM, Ben Gamari wrote: | > Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: | > | > > A 'sh validate` in a clean tree fails as below. | > > Is that expected? That is, is validate dead? | > > If so let's change the shell script to say "game over, just use | > > Hadrian". | > > Simon | > | > John, it looks like this is more fallout from the recent platform | > changes. Any thoughts? | > | > Cheers, | > | > - Ben | > | > > "inplace/bin/ghc-cabal" check libraries/ghc-prim | > > | > > "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install | > > --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" | > > --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg" | > > --disable-library-for-ghci --enable-library-vanilla | > > --enable-library-for-ghci --disable-library-profiling --enable-shared | --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable -Wno- | error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" | > > " --gcc-options="-Wall -Werror=unused-but-set-variable -Wno- | error=inline " --with-gcc="gcc" | > > --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" --with- | happy="/usr/bin/happy" | > > | > > Configuring ghc-prim-0.6.1... | > > | > > ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited | > > with an | > > | > > error: | > > | > > No entry for "target platform string" in | > > | > > "/home/simonpj/code/HEAD/inplace/lib/settings" | > > | > > libraries/ghc-prim/ghc.mk:4: recipe for target | > > 'libraries/ghc-prim/dist-install/package-data.mk' failed | > > | > > make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error | > > 1 | > > | > > Makefile:123: recipe for target 'all' failed | > > | > > make: *** [all] Error 2 | > | > | > *Attachments:* | > * signature.asc

1 0

Clean build fails with make
by Simon Peyton Jones 28 May '19

28 May '19

A 'sh validate` in a clean tree fails as below. Is that expected? That is, is validate dead? If so let's change the shell script to say "game over, just use Hadrian". Simon "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --enable-shared --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited with an error: No entry for "target platform string" in "/home/simonpj/code/HEAD/inplace/lib/settings" libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2

2 1