From lemming at henning-thielemann.de Sat Jan 2 12:21:53 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 2 Jan 2016 13:21:53 +0100 (CET) Subject: prelude-compat, prelude2010 Message-ID: Here is my attempt to make packages compile with GHC-7.10 and older compilers without warnings: https://hackage.haskell.org/package/prelude-compat-0.0/candidate https://hackage.haskell.org/package/prelude2010-0.0/candidate The idea is that prelude2010:Prelude maintains the export list of haskell2010:Prelude such that you are saved both from identifier conflicts and warnings about redundant imports of Data.Foldable etc. Unfortunately, when I try to use it on GHC-7.8.4 together with base-noprelude, I am told that base-noprelude cannot be installed with Cabal-1.22. :-( However, when thinking about adapting all my packages to this work-around I'd prefer to switch to the real solution, namely split base packages that can be upgraded independently from GHC. From lemming at henning-thielemann.de Sun Jan 3 21:11:24 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 3 Jan 2016 22:11:24 +0100 (CET) Subject: Foldable.Mapped Message-ID: I found the following data type useful when working with the Foldable class: {- | It holds: > foldMap f . Mapped g = foldMap f . fmap g but use of 'Mapped' avoids 'Functor' constraint. -} data Mapped f a b = Mapped (a -> b) (f a) instance (Foldable f) => Foldable (Mapped f a) where foldMap g (Mapped f xs) = Fold.foldMap (g . f) xs foldr g x (Mapped f xs) = Fold.foldr (g . f) x xs foldl g x (Mapped f xs) = Fold.foldl (\acc -> g acc . f) x xs Should it be added to Data.Foldable? From ollie at ocharles.org.uk Mon Jan 4 00:43:07 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Mon, 04 Jan 2016 00:43:07 +0000 Subject: Foldable.Mapped In-Reply-To: References: Message-ID: Could you provide some examples where you have found it useful? On Sun, Jan 3, 2016 at 9:11 PM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > I found the following data type useful when working with the Foldable > class: > > > {- | > It holds: > > > foldMap f . Mapped g = foldMap f . fmap g > > but use of 'Mapped' avoids 'Functor' constraint. > -} > data Mapped f a b = Mapped (a -> b) (f a) > > > instance (Foldable f) => Foldable (Mapped f a) where > foldMap g (Mapped f xs) = Fold.foldMap (g . f) xs > foldr g x (Mapped f xs) = Fold.foldr (g . f) x xs > foldl g x (Mapped f xs) = Fold.foldl (\acc -> g acc . f) x xs > > > Should it be added to Data.Foldable? > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jan 4 01:11:26 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 4 Jan 2016 02:11:26 +0100 (CET) Subject: Foldable.Mapped In-Reply-To: References: Message-ID: On Mon, 4 Jan 2016, Oliver Charles wrote: > Could you provide some examples where you have found it useful? E.g. Set has Foldable instance, but not Functor. Using Mapped I can implement argmax in a generic way, such that it also works on Set. argmax :: (Ord b, Foldable f) => (a -> b) -> f a -> a argmax f = snd . Fold.maximumBy (comparing fst) . Mapped (\a -> (f a, a)) From shachaf at gmail.com Mon Jan 4 01:21:16 2016 From: shachaf at gmail.com (Shachaf Ben-Kiki) Date: Sun, 3 Jan 2016 17:21:16 -0800 Subject: Foldable.Mapped In-Reply-To: References: Message-ID: It sounds like Coyoneda -- i.e. Mapped with the "a" existential -- might be what you're looking for: http://hackage.haskell.org/package/kan-extensions-4.2.3/docs/Data-Functor-Coyoneda.html Shachaf On Sun, Jan 3, 2016 at 5:11 PM, Henning Thielemann wrote: > > On Mon, 4 Jan 2016, Oliver Charles wrote: > >> Could you provide some examples where you have found it useful? > > > E.g. Set has Foldable instance, but not Functor. Using Mapped I can > implement argmax in a generic way, such that it also works on Set. > > argmax :: (Ord b, Foldable f) => (a -> b) -> f a -> a > argmax f = snd . Fold.maximumBy (comparing fst) . Mapped (\a -> (f a, a)) > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From david.feuer at gmail.com Mon Jan 4 05:25:41 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 4 Jan 2016 00:25:41 -0500 Subject: Foldable.Mapped In-Reply-To: References: Message-ID: That's what I was thinking too. While that's not Haskell 98, I believe it can be justified on Haskell 98 grounds by approximate equivalence with the representation of a foldable container by a binary tree. I'm no expert, but I think the hypothetical alternative formulation might look like this: --Free magma data Tree a = Leaf a | Bin (Tree a) (Tree a) deriving (Functor, Foldable) --Adjoin an identity and a phantom. --The phantom isn't Haskell 98, but --it would be possible to accomplish the --same purpose in Haskell 98 data R (f :: * -> *) a = Empty | FM (Tree a) deriving (Functor, Foldable) --Improper, but probably sane for the purpose instance Monoid (R f a) where mempty = Empty mappend Empty ys = ys mappend xs Empty = xs mappend (FM xs) (FM ys) = FM (Bin xs ys) rep :: Foldable f => f a -> R f a rep = foldMap (FM . Leaf) We can apply rep to a foldable container to get a reusable representation of that container for folding purposes that is also a Functor. On Jan 3, 2016 8:21 PM, "Shachaf Ben-Kiki" wrote: > It sounds like Coyoneda -- i.e. Mapped with the "a" existential -- > might be what you're looking for: > > http://hackage.haskell.org/package/kan-extensions-4.2.3/docs/Data-Functor-Coyoneda.html > > Shachaf > > On Sun, Jan 3, 2016 at 5:11 PM, Henning Thielemann > wrote: > > > > On Mon, 4 Jan 2016, Oliver Charles wrote: > > > >> Could you provide some examples where you have found it useful? > > > > > > E.g. Set has Foldable instance, but not Functor. Using Mapped I can > > implement argmax in a generic way, such that it also works on Set. > > > > argmax :: (Ord b, Foldable f) => (a -> b) -> f a -> a > > argmax f = snd . Fold.maximumBy (comparing fst) . Mapped (\a -> (f a, a)) > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Jan 10 13:08:54 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 10 Jan 2016 14:08:54 +0100 (CET) Subject: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec Message-ID: In transformers-0.5:Data.Functor.Classes class methods like eq1 are replaced by liftEq. With transformers-0.4 I could define: data T a = complicated definition ... deriving (Eq, Ord, Show) instance Eq1 T where eq1 = (==) instance Ord1 T where compare1 = compare instance Show1 T where showsPrec1 = showsPrec In transformers-0.5 it seems that I have to implement Eq1, Ord1, Show1 instances manually. Is there some assistance to define eq1 and compare1 for an ADT? What are the use cases where eq1 was not powerful enough and liftEq is needed? From ryan.gl.scott at gmail.com Mon Jan 11 15:00:44 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 11 Jan 2016 10:00:44 -0500 Subject: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec Message-ID: > In transformers-0.5 it seems that I have to implement Eq1, Ord1, Show1 instances manually. For better or worse, that is indeed the case. Before, Eq1/Ord1/Read1/Show1 relied on the type argument having an implicit dictionary to use, which is why you could get away with piggybacking off of your existing Eq/Ord/Read/Show instances. Now, Eq1, Eq2, and friends rely on explicit dictionary passing, so they're strictly more powerful than Eq et al. > Is there some assistance to define eq1 and compare1 for an ADT? At the moment, no. Sometime in the future, I want to do two things which should make the situation a little better: 1. Write a language extension to derive Eq1/Eq2/etc. It definitely won't be making it into GHC 8.0 due to time constraints, plus I need to propose a design. And... 2. ...I should write a Template Haskell shim which implements the proposed design. I already have a package called deriving-compat [1] which has done this (but only for recent changes to -XDeriveFoldable), so that would probably be a logical place to put it. Until then, if you need to hand-roll Eq1/Eq2/etc. instances that align with your Eq instances, I'd recommend copying the output of ghc -ddump-deriv, copying the generated instances, and replacing the necessary calls with dictionary arguments. For example, given this instance: data Example a = Example Int a deriving Eq Compiling with ghc -ddump-deriv gives you this (after some code cleanup): instance Eq a => Eq (Example a) where Example i1 a1 == Example i2 a2 = i1 == i2 && a1 == a2 e1 /= e2 = not (e1 == e2) Then, you can create an Eq1 instance with some minor adjustments: instance Eq1 Example where liftEq eq (Example i1 a1) (Example i2 a2) = i1 == i2 && eq a1 a2 > What are the use cases where eq1 was not powerful enough and liftEq is needed? The previous type signature of Data.Functor.Classes in transformers-0.4 resulted in some awkward instances, a prime example being found in Data.Functor.Compose: import Data.Functor.Classes(Eq1(..)) newtype Compose f g a = Compose (f (g a)) instance (Functor f, Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a) where Compose x == Compose y = eq1 (fmap Apply x) (fmap Apply y) instance (Functor f, Eq1 f, Eq1 g) => Eq1 (Compose f g) where eq1 = (==) newtype Apply g a = Apply (g a) instance (Eq1 g, Eq a) => Eq (Apply g a) where Apply x == Apply y = eq1 x y This is a super-kludgey instance because it requires f to be a Functor instance. In general, having these Functor constraints pop up everywhere results in less efficient instances, and it won't work at all for many GADT-like constructions that can't have legal Functor instances. With the new API, there is no need for these Functor constraints: import Data.Functor.Classes(Eq1(..)) newtype Compose f g a = Compose (f (g a)) instance (Eq1 f, Eq1 g) => Eq1 (Compose f g) where liftEq eq (Compose x) (Compose y) = liftEq (liftEq eq) x y Ryan S. ----- [1] http://hackage.haskell.org/package/deriving-compat From m.farkasdyck at gmail.com Mon Jan 11 17:29:51 2016 From: m.farkasdyck at gmail.com (M Farkas-Dyck) Date: Mon, 11 Jan 2016 09:29:51 -0800 Subject: Proposal: Add Peano numbers to base Message-ID: I have seen these redefined many times now. Examples: https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.html#t:Nat https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.html#t:T https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.html#t:N https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.html#t:Nat https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano I often see them used as DataKinds. Too, operations on them can be lazy, which is sometimes useful. I filed a ticket: https://ghc.haskell.org/trac/ghc/ticket/11402 Discussion period: 2 weeks From lemming at henning-thielemann.de Mon Jan 11 17:45:10 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 11 Jan 2016 18:45:10 +0100 (CET) Subject: Proposal: Add Peano numbers to base In-Reply-To: References: Message-ID: On Mon, 11 Jan 2016, M Farkas-Dyck wrote: > I have seen these redefined many times now. Examples: > https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.html#t:Nat > https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.html#t:T > https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.html#t:N > https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.html#t:Nat > https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano Type-level Peano number are also contained in: https://hackage.haskell.org/package/tfp-1.0.0.2/docs/Type-Data-Num-Unary.html and data-level Peano numbers in this playground module: http://code.haskell.org/~thielema/htam/src/Number/PeanoNumber.hs I'd prefer that 'base' shrinks rather than grows. If we find that people like one implementation most, you could bless it by adding it to the Haskell platform. You might add a comparison of the packages to the Wiki page: https://wiki.haskell.org/Peano_numbers From johnw at newartisans.com Mon Jan 11 17:59:07 2016 From: johnw at newartisans.com (John Wiegley) Date: Mon, 11 Jan 2016 09:59:07 -0800 Subject: Proposal: Add Peano numbers to base In-Reply-To: (Henning Thielemann's message of "Mon, 11 Jan 2016 18:45:10 +0100 (CET)") References: Message-ID: >>>>> Henning Thielemann writes: > I'd prefer that 'base' shrinks rather than grows. If we find that people > like one implementation most, you could bless it by adding it to the Haskell > platform. +1 -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From lemming at henning-thielemann.de Mon Jan 11 18:55:40 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 11 Jan 2016 19:55:40 +0100 (CET) Subject: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec In-Reply-To: References: Message-ID: On Mon, 11 Jan 2016, Ryan Scott wrote: >> What are the use cases where eq1 was not powerful enough and liftEq is needed? > > The previous type signature of Data.Functor.Classes in > transformers-0.4 resulted in some awkward instances, a prime example > being found in Data.Functor.Compose: > > import Data.Functor.Classes(Eq1(..)) > > newtype Compose f g a = Compose (f (g a)) > instance (Functor f, Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a) where > Compose x == Compose y = eq1 (fmap Apply x) (fmap Apply y) > instance (Functor f, Eq1 f, Eq1 g) => Eq1 (Compose f g) where eq1 = (==) > > newtype Apply g a = Apply (g a) > instance (Eq1 g, Eq a) => Eq (Apply g a) where > Apply x == Apply y = eq1 x y Btw. I already defined my own Apply type (I called it Wrap) because I found it useful. Would you mind to export it from 'transformers'? From ryan.gl.scott at gmail.com Mon Jan 11 19:04:05 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 11 Jan 2016 14:04:05 -0500 Subject: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec In-Reply-To: References: Message-ID: > Btw. I already defined my own Apply type (I called it Wrap) because I found it useful. Would you mind to export it from 'transformers'? You're talking about this transformers issue [1], correct? If so, I doubt that's ever going to happen. The changes to Eq1/Ord1/Read1/Show1 rendered Apply obsolete, since it's no longer necessary to use Apply to define Eq1 instances for nested applications of a type parameter of kind * -> *. Not only that, but there are a couple of datatypes in transformers that already resolve their Eq instances in an identical way to how Apply would (for instance, IdentityT, which is isomorphic to Apply [2]). Ryan S. ----- [1] http://hub.darcs.net/ross/transformers/issue/8 [2] http://hackage.haskell.org/package/transformers-0.5.0.0/docs/src/Control-Monad-Trans-Identity.html#line-55 From lemming at henning-thielemann.de Mon Jan 11 19:10:48 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 11 Jan 2016 20:10:48 +0100 (CET) Subject: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec In-Reply-To: References: Message-ID: On Mon, 11 Jan 2016, Ryan Scott wrote: > Not only that, but there are a couple of datatypes in transformers that > already resolve their Eq instances in an identical way to how Apply > would (for instance, IdentityT, which is isomorphic to Apply [2]). If IdentityT is my desired Apply/Wrap then I am happy. From lemming at henning-thielemann.de Mon Jan 11 19:20:46 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 11 Jan 2016 20:20:46 +0100 (CET) Subject: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec In-Reply-To: References: Message-ID: me again ... On Mon, 11 Jan 2016, Ryan Scott wrote: > You're talking about this transformers issue [1], correct? yes > Not only that, but there are a couple of datatypes in transformers that > already resolve their Eq instances in an identical way to how Apply > would (for instance, IdentityT, which is isomorphic to Apply [2]). One of my applications is to use functor things in a Set, which requires Ord constraint. With IdentityT I can write: class Ord1 f => Elem f where method :: ... transform :: (Elem f, Ord a) => Set (IdentityT f a) -> Set (IdentityT f a) Without IdentityT I would have constraint (Ord (f a)). From wren at community.haskell.org Mon Jan 11 23:16:12 2016 From: wren at community.haskell.org (wren romano) Date: Mon, 11 Jan 2016 18:16:12 -0500 Subject: Proposal: Add Peano numbers to base In-Reply-To: References: Message-ID: On Mon, Jan 11, 2016 at 12:29 PM, M Farkas-Dyck wrote: > I have seen these redefined many times now. Examples: > https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.html#t:Nat > https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.html#t:T > https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.html#t:N > https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.html#t:Nat > https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano > > I often see them used as DataKinds. Too, operations on them can be > lazy, which is sometimes useful. > > I filed a ticket: https://ghc.haskell.org/trac/ghc/ticket/11402 I'm a fan of blessing some particular implementation in order to minimize the code redundancy. Though I'd prolly suggest making it a Platform package rather than rolling it into base itself (unless there's some reason why it needs to be in base itself). Wherever it ends up, I really like that the patch names the type Peano rather than Nat. I often use Nat as a newtype of Int (and Natural as a newtype of Integer) for when I need efficient implementations of natural numbers, so it's nice to give the lazy unary representation a different name. -- Live well, ~wren From alexander at plaimi.net Tue Jan 12 08:31:52 2016 From: alexander at plaimi.net (Alexander Berntsen) Date: Tue, 12 Jan 2016 09:31:52 +0100 Subject: Proposal: Add Peano numbers to base In-Reply-To: References: Message-ID: <5694B9F8.90103@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/01/16 18:59, John Wiegley wrote: >>>>>> Henning Thielemann >>>>>> writes: >> I'd prefer that 'base' shrinks rather than grows. If we find >> that people like one implementation most, you could bless it by >> adding it to the Haskell platform. > > +1 I don't necessarily want base to shrink as such, but I certainly think the *scope* of base could stand to shrink. Furthermore, I don't see much value in adding this to base. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWlLn3AAoJENQqWdRUGk8BxPwQANRcPTJik63XBaTQvg6Pn59v litf0OksO+ACtT9Sdw2LdU0AJYXpdcg8MdMp5YDW3S0UTTeyr3EFgoioFirU0XVb icupB1RGvwkn+oD3d+vmdPncIi8/HzHbaxCph1OiOoB2//IGPVlo3q++GS9VXBkU 79ii3FsU4ofzRkMaalicKobOHV06JX3z0LahC1qc9jU9lLq14WaCIJg1wA/aCVBa S7PgcJE+itirCPDIOpJ7LlPSIpwFzix5eJvXZmYUL+sSxO/wpYJ2bXTUD3xZUq3d +q3cfg5+TMjm7yiPQmlkdLBjARZsLBpFMrxhZnrW2xUdAvvZZIaBFGIvE8TPWWHD mGIYNee/SPK4W7p5B4MA3ie+y/+glma/RXEZms3uDCThPI0DTsIZHo6s6tT3W7sB /ceHrgzMfsqflc8zIM1uyMY4Poy+N8wiwN8qnCkhF0s0TpORoBz9l+QBx+t72Lgm 3Gy6P9In4QeUrTrnYnJk/7bgwgY6s8fjBJ/OhURvavoyX8C60zNej9ChyYBybmQA QdIbNVfjEYRk6ED4r62fhCaacNsn9EJIfVzxiGqvNPsOIJWZ2QX/vrXo+azLjnoB ClqtDYQMdSiNAClsA0EKhxnf5/+3n6vsAwlzPegf6tczpOCSTHDUEW6W58AH9Sn4 c4fuhx3Q24wWkySIFnGZ =xwFn -----END PGP SIGNATURE----- From amindfv at gmail.com Tue Jan 12 09:12:44 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Tue, 12 Jan 2016 04:12:44 -0500 Subject: Proposal: Add Peano numbers to base In-Reply-To: <5694B9F8.90103@plaimi.net> References: <5694B9F8.90103@plaimi.net> Message-ID: +1 to blessed, +0 to it being in base (agreed re: shrinking base) Tom > El 12 ene 2016, a las 03:31, Alexander Berntsen escribi?: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 11/01/16 18:59, John Wiegley wrote: >>>>>>> Henning Thielemann >>>>>>> writes: >>> I'd prefer that 'base' shrinks rather than grows. If we find >>> that people like one implementation most, you could bless it by >>> adding it to the Haskell platform. >> >> +1 > I don't necessarily want base to shrink as such, but I certainly think > the *scope* of base could stand to shrink. Furthermore, I don't see > much value in adding this to base. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJWlLn3AAoJENQqWdRUGk8BxPwQANRcPTJik63XBaTQvg6Pn59v > litf0OksO+ACtT9Sdw2LdU0AJYXpdcg8MdMp5YDW3S0UTTeyr3EFgoioFirU0XVb > icupB1RGvwkn+oD3d+vmdPncIi8/HzHbaxCph1OiOoB2//IGPVlo3q++GS9VXBkU > 79ii3FsU4ofzRkMaalicKobOHV06JX3z0LahC1qc9jU9lLq14WaCIJg1wA/aCVBa > S7PgcJE+itirCPDIOpJ7LlPSIpwFzix5eJvXZmYUL+sSxO/wpYJ2bXTUD3xZUq3d > +q3cfg5+TMjm7yiPQmlkdLBjARZsLBpFMrxhZnrW2xUdAvvZZIaBFGIvE8TPWWHD > mGIYNee/SPK4W7p5B4MA3ie+y/+glma/RXEZms3uDCThPI0DTsIZHo6s6tT3W7sB > /ceHrgzMfsqflc8zIM1uyMY4Poy+N8wiwN8qnCkhF0s0TpORoBz9l+QBx+t72Lgm > 3Gy6P9In4QeUrTrnYnJk/7bgwgY6s8fjBJ/OhURvavoyX8C60zNej9ChyYBybmQA > QdIbNVfjEYRk6ED4r62fhCaacNsn9EJIfVzxiGqvNPsOIJWZ2QX/vrXo+azLjnoB > ClqtDYQMdSiNAClsA0EKhxnf5/+3n6vsAwlzPegf6tczpOCSTHDUEW6W58AH9Sn4 > c4fuhx3Q24wWkySIFnGZ > =xwFn > -----END PGP SIGNATURE----- > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From alois.cochard at gmail.com Tue Jan 12 09:34:18 2016 From: alois.cochard at gmail.com (Alois Cochard) Date: Tue, 12 Jan 2016 10:34:18 +0100 Subject: Proposal: Add Peano numbers to base In-Reply-To: References: Message-ID: On 11 January 2016 at 18:45, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 11 Jan 2016, M Farkas-Dyck wrote: > > I have seen these redefined many times now. Examples: >> >> https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano.html#t:Nat >> >> https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano.html#t:T >> >> https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.html#t:N >> >> https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.html#t:Nat >> >> https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano >> > > Type-level Peano number are also contained in: > > https://hackage.haskell.org/package/tfp-1.0.0.2/docs/Type-Data-Num-Unary.html > > and data-level Peano numbers in this playground module: > http://code.haskell.org/~thielema/htam/src/Number/PeanoNumber.hs > > > I'd prefer that 'base' shrinks rather than grows. If we find that people > like one implementation most, you could bless it by adding it to the > Haskell platform. > > Same here, -1 on adding a particular implementation into base. > You might add a comparison of the packages to the Wiki page: > https://wiki.haskell.org/Peano_numbers > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed Jan 13 01:28:01 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 12 Jan 2016 17:28:01 -0800 Subject: GHC.Generics and instances of Functor, Applicative, etc? Message-ID: I'm using GHC.Generics and have noticed that the data types defined there don't have instances of the standard classes (at least not defined in that module), such as Functor, Applicative, Foldable and Traversable. It'd be very useful to be able to rely on such instances, so that one can define instances of custom types via instances of the generic types. (Hopefully, the compiler can remove most or all conversion overhead) Is there any reason not to add these generic instances? -- Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Jan 13 03:23:01 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 12 Jan 2016 22:23:01 -0500 Subject: GHC.Generics and instances of Functor, Applicative, etc? In-Reply-To: References: Message-ID: https://ghc.haskell.org/trac/ghc/ticket/9043 is the current ticket for tracking this and has more details. On Tue, Jan 12, 2016 at 8:28 PM, Conal Elliott wrote: > I'm using GHC.Generics and have noticed that the data types defined there > don't have instances of the standard classes (at least not defined in that > module), such as Functor, Applicative, Foldable and Traversable. It'd be > very useful to be able to rely on such instances, so that one can define > instances of custom types via instances of the generic types. (Hopefully, > the compiler can remove most or all conversion overhead) Is there any > reason not to add these generic instances? > > -- Conal > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Wed Jan 13 03:26:08 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 12 Jan 2016 19:26:08 -0800 Subject: GHC.Generics and instances of Functor, Applicative, etc? In-Reply-To: References: Message-ID: Lovely. Thanks! On Tue, Jan 12, 2016 at 7:23 PM, Edward Kmett wrote: > https://ghc.haskell.org/trac/ghc/ticket/9043 is the current ticket for > tracking this and has more details. > > On Tue, Jan 12, 2016 at 8:28 PM, Conal Elliott wrote: > >> I'm using GHC.Generics and have noticed that the data types defined there >> don't have instances of the standard classes (at least not defined in that >> module), such as Functor, Applicative, Foldable and Traversable. It'd be >> very useful to be able to rely on such instances, so that one can define >> instances of custom types via instances of the generic types. (Hopefully, >> the compiler can remove most or all conversion overhead) Is there any >> reason not to add these generic instances? >> >> -- Conal >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Jan 13 05:58:17 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 13 Jan 2016 00:58:17 -0500 Subject: Proposal: Add Semigroup and Monoid instances for (:~:) Message-ID: These are not likely to be *useful*, but they fall easily into the general bucket of "exactly one sensible instance exists". instance Semigroup (a :~: b) where r <> _ = r instance a ~ b => Monoid (a :~: b) where mempty = Refl mappend r _ = r From andreas.abel at ifi.lmu.de Thu Jan 14 13:56:34 2016 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Thu, 14 Jan 2016 14:56:34 +0100 Subject: Proposal: Add Semigroup and Monoid instances for (:~:) In-Reply-To: References: Message-ID: <5697A912.4040604@ifi.lmu.de> What does this smiley :~: stand for? On 13.01.2016 06:58, David Feuer wrote: > These are not likely to be *useful*, but they fall easily into the > general bucket of "exactly one sensible instance exists". > > instance Semigroup (a :~: b) where > r <> _ = r > > instance a ~ b => Monoid (a :~: b) where > mempty = Refl > mappend r _ = r > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From ollie at ocharles.org.uk Thu Jan 14 14:02:37 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 14 Jan 2016 14:02:37 +0000 Subject: Proposal: Add Semigroup and Monoid instances for (:~:) In-Reply-To: <5697A912.4040604@ifi.lmu.de> References: <5697A912.4040604@ifi.lmu.de> Message-ID: Refl, I believe. On Thu, Jan 14, 2016 at 1:56 PM Andreas Abel wrote: > What does this smiley :~: stand for? > > On 13.01.2016 06:58, David Feuer wrote: > > These are not likely to be *useful*, but they fall easily into the > > general bucket of "exactly one sensible instance exists". > > > > instance Semigroup (a :~: b) where > > r <> _ = r > > > > instance a ~ b => Monoid (a :~: b) where > > mempty = Refl > > mappend r _ = r > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www2.tcs.ifi.lmu.de/~abel/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Jan 14 14:08:45 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 14 Jan 2016 09:08:45 -0500 Subject: Proposal: Add Semigroup and Monoid instances for (:~:) In-Reply-To: <5697A912.4040604@ifi.lmu.de> References: <5697A912.4040604@ifi.lmu.de> Message-ID: (:~:) is from Data.Type.Equality. data a :~: b where Refl :: a :~: a On Jan 14, 2016 8:56 AM, "Andreas Abel" wrote: > What does this smiley :~: stand for? > > On 13.01.2016 06:58, David Feuer wrote: > >> These are not likely to be *useful*, but they fall easily into the >> general bucket of "exactly one sensible instance exists". >> >> instance Semigroup (a :~: b) where >> r <> _ = r >> >> instance a ~ b => Monoid (a :~: b) where >> mempty = Refl >> mappend r _ = r >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www2.tcs.ifi.lmu.de/~abel/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.farkasdyck at gmail.com Fri Jan 15 03:30:43 2016 From: m.farkasdyck at gmail.com (M Farkas-Dyck) Date: Thu, 14 Jan 2016 19:30:43 -0800 Subject: Proposal: Add Peano numbers to base In-Reply-To: References: Message-ID: This seems a clear consensus, so henceforth i consider this proposal dead. From ryan.gl.scott at gmail.com Mon Jan 18 00:02:42 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sun, 17 Jan 2016 19:02:42 -0500 Subject: Proposal: Add Semigroup and Monoid instances for (:~:) Message-ID: +1, with a one stipulation: I'd rather the Semigroup instance be: instance Semigroup (a :~: b) where Refl <> Refl = Refl and similarly for Monoid(mappend). It's a minor quibble, but the documentation [1] for (:~:) says that there's only a proof term for a ~ b if it's inhabited by a terminating value, so performing a strict pattern match seems like the best default here. Ryan S. ----- [1] http://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Type-Equality.html#t::-126-: From david.feuer at gmail.com Mon Jan 18 00:15:40 2016 From: david.feuer at gmail.com (David Feuer) Date: Sun, 17 Jan 2016 19:15:40 -0500 Subject: Proposal: Add Semigroup and Monoid instances for (:~:) In-Reply-To: References: Message-ID: The definitions I gave for <> and mappend are each strict in the left argument, which is enough to ensure soundness--if (x :: a :~: b) <> (y :: a :~: b) is not bottom, then surely x is not bottom, so a :~: b. So this is really only a question of efficiency. I don't have a very strong opinion myself, but I think we might be better off leaving things lazy in the second argument. On Sun, Jan 17, 2016 at 7:02 PM, Ryan Scott wrote: > +1, with a one stipulation: I'd rather the Semigroup instance be: > > instance Semigroup (a :~: b) where > Refl <> Refl = Refl > > and similarly for Monoid(mappend). It's a minor quibble, but the > documentation [1] for (:~:) says that there's only a proof term for a > ~ b if it's inhabited by a terminating value, so performing a strict > pattern match seems like the best default here. > > Ryan S. > ----- > [1] http://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Type-Equality.html#t::-126-: > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From ryan.gl.scott at gmail.com Mon Jan 18 00:21:38 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Sun, 17 Jan 2016 19:21:38 -0500 Subject: Proposal: Add Semigroup and Monoid instances for (:~:) In-Reply-To: References: Message-ID: OK, you (and Eric Mertens) have convinced me. I was originally put off by the fact that r <> _ = r is (technically) lazy, but you'd still need to strictly pattern-match on the result anyway in order to bring evidence that a ~ b into scope, so it's not an issue like I thought it was. Unconditional +1 from me. Ryan S. On Sun, Jan 17, 2016 at 7:15 PM, David Feuer wrote: > The definitions I gave for <> and mappend are each strict in the left > argument, which is enough to ensure soundness--if (x :: a :~: b) <> > (y :: a :~: b) is not bottom, then surely x is not bottom, so a :~: b. > So this is really only a question of efficiency. I don't have a very > strong opinion myself, but I think we might be better off leaving > things lazy in the second argument. > > On Sun, Jan 17, 2016 at 7:02 PM, Ryan Scott > wrote: > > +1, with a one stipulation: I'd rather the Semigroup instance be: > > > > instance Semigroup (a :~: b) where > > Refl <> Refl = Refl > > > > and similarly for Monoid(mappend). It's a minor quibble, but the > > documentation [1] for (:~:) says that there's only a proof term for a > > ~ b if it's inhabited by a terminating value, so performing a strict > > pattern match seems like the best default here. > > > > Ryan S. > > ----- > > [1] > http://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Type-Equality.html#t::-126- > : > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Mon Jan 18 02:17:44 2016 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Mon, 18 Jan 2016 03:17:44 +0100 Subject: Proposal: Data.Bool.implies Message-ID: <569C4B48.6060507@nh2.me> I propose to add to Data.Bool: -- | Boolean implication. implies :: Bool -> Bool -> Bool implies True x = x implies False _ = True infix 4 `implies` -- same as (==) The request for this is quite old (see e.g. http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html). I believe that by not trying to use an operator for it, and keeping it in Data.Bool, we can avoid doing anything wrong. A quick superficial search on Stackage Hoogle suggests that adding this function should create no breakage (4 packages define their own function called `implies`, none of them import Data.Bool). `infix` instead of `infixl` or `infixr` to force you to bracket it; for the same reason it has the same precedence as `==`. From david.feuer at gmail.com Mon Jan 18 04:12:03 2016 From: david.feuer at gmail.com (David Feuer) Date: Sun, 17 Jan 2016 23:12:03 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: <569C4B48.6060507@nh2.me> References: <569C4B48.6060507@nh2.me> Message-ID: -1. We already have a `<=` operator. On Sun, Jan 17, 2016 at 9:17 PM, Niklas Hamb?chen wrote: > I propose to add to Data.Bool: > > -- | Boolean implication. > implies :: Bool -> Bool -> Bool > implies True x = x > implies False _ = True > > infix 4 `implies` -- same as (==) > > The request for this is quite old (see e.g. > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html). > > I believe that by not trying to use an operator for it, and keeping it > in Data.Bool, we can avoid doing anything wrong. > > A quick superficial search on Stackage Hoogle suggests that adding this > function should create no breakage (4 packages define their own function > called `implies`, none of them import Data.Bool). > > `infix` instead of `infixl` or `infixr` to force you to bracket it; for > the same reason it has the same precedence as `==`. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From evincarofautumn at gmail.com Mon Jan 18 05:23:26 2016 From: evincarofautumn at gmail.com (Jon Purdy) Date: Sun, 17 Jan 2016 21:23:26 -0800 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: +1. ?<=? has the wrong strictness. In ?a `implies` b?, ?b? should not be evaluated if ?a? is false. As a strawman, I?d propose that the Ord instance for Bool be changed?but this is more likely to break existing code, however slightly. On Sun, Jan 17, 2016 at 8:12 PM, David Feuer wrote: > -1. We already have a `<=` operator. > > On Sun, Jan 17, 2016 at 9:17 PM, Niklas Hamb?chen wrote: > > I propose to add to Data.Bool: > > > > -- | Boolean implication. > > implies :: Bool -> Bool -> Bool > > implies True x = x > > implies False _ = True > > > > infix 4 `implies` -- same as (==) > > > > The request for this is quite old (see e.g. > > > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html > ). > > > > I believe that by not trying to use an operator for it, and keeping it > > in Data.Bool, we can avoid doing anything wrong. > > > > A quick superficial search on Stackage Hoogle suggests that adding this > > function should create no breakage (4 packages define their own function > > called `implies`, none of them import Data.Bool). > > > > `infix` instead of `infixl` or `infixr` to force you to bracket it; for > > the same reason it has the same precedence as `==`. > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Jan 18 06:14:21 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 01:14:21 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: I think changing the Ord instance for Bool *may* be the way to go. Yes, the lazy one is likely a bit less efficient in some cases, but I somehow doubt many are relying on it to be fast. Moreover, people expect most Bool operations to short-circuit (I even seem to have lost that fight wrt the Data.Bits operations, which I firmly believe should be *strict*). instance Ord Bool where False <= _ = True True <= x = x True >= _ = True False >= x = not x False < x = x True < _ = False False > _ = False True > x = not x On Mon, Jan 18, 2016 at 12:23 AM, Jon Purdy wrote: > +1. ?<=? has the wrong strictness. In ?a `implies` b?, ?b? should not be > evaluated if ?a? is false. > > As a strawman, I?d propose that the Ord instance for Bool be changed?but > this is more likely to break existing code, however slightly. > > On Sun, Jan 17, 2016 at 8:12 PM, David Feuer wrote: >> >> -1. We already have a `<=` operator. >> >> On Sun, Jan 17, 2016 at 9:17 PM, Niklas Hamb?chen wrote: >> > I propose to add to Data.Bool: >> > >> > -- | Boolean implication. >> > implies :: Bool -> Bool -> Bool >> > implies True x = x >> > implies False _ = True >> > >> > infix 4 `implies` -- same as (==) >> > >> > The request for this is quite old (see e.g. >> > >> > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html). >> > >> > I believe that by not trying to use an operator for it, and keeping it >> > in Data.Bool, we can avoid doing anything wrong. >> > >> > A quick superficial search on Stackage Hoogle suggests that adding this >> > function should create no breakage (4 packages define their own function >> > called `implies`, none of them import Data.Bool). >> > >> > `infix` instead of `infixl` or `infixr` to force you to bracket it; for >> > the same reason it has the same precedence as `==`. >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > From spam at scientician.net Mon Jan 18 06:41:10 2016 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 18 Jan 2016 07:41:10 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: On 01/18/2016 07:14 AM, David Feuer wrote: > I think changing the Ord instance for Bool *may* be the way to go. If that happens then perhaps an "implies" alias in Data.Bool might still be relevant? I, for one, would almost certainly not have discovered "<=" if I were looking for this function. That said, I don't think I've ever had a need for "implies", so... +0 for an alias, I guess. From qdunkan at gmail.com Mon Jan 18 06:57:01 2016 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 18 Jan 2016 12:27:01 +0530 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: I have only very rarely needed 'implies' and when I do I'm happy with 'if a then b else False'. But if I needed to do that a lot, I would write my own function and certainly never use (<=), because I wouldn't guess that (<=) has the same logic as implies. And even if it does, isn't the means more important than the end? For the same reason I wouldn't write 'not a || b' because when I want to say implies I'll just directly say implies. On Mon, Jan 18, 2016 at 11:44 AM, David Feuer wrote: > I think changing the Ord instance for Bool *may* be the way to go. > Yes, the lazy one is likely a bit less efficient in some cases, but I > somehow doubt many are relying on it to be fast. Moreover, people > expect most Bool operations to short-circuit (I even seem to have lost > that fight wrt the Data.Bits operations, which I firmly believe should > be *strict*). > > instance Ord Bool where > False <= _ = True > True <= x = x > > True >= _ = True > False >= x = not x > > False < x = x > True < _ = False > > False > _ = False > True > x = not x > > > On Mon, Jan 18, 2016 at 12:23 AM, Jon Purdy wrote: >> +1. ?<=? has the wrong strictness. In ?a `implies` b?, ?b? should not be >> evaluated if ?a? is false. >> >> As a strawman, I?d propose that the Ord instance for Bool be changed?but >> this is more likely to break existing code, however slightly. >> >> On Sun, Jan 17, 2016 at 8:12 PM, David Feuer wrote: >>> >>> -1. We already have a `<=` operator. >>> >>> On Sun, Jan 17, 2016 at 9:17 PM, Niklas Hamb?chen wrote: >>> > I propose to add to Data.Bool: >>> > >>> > -- | Boolean implication. >>> > implies :: Bool -> Bool -> Bool >>> > implies True x = x >>> > implies False _ = True >>> > >>> > infix 4 `implies` -- same as (==) >>> > >>> > The request for this is quite old (see e.g. >>> > >>> > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html). >>> > >>> > I believe that by not trying to use an operator for it, and keeping it >>> > in Data.Bool, we can avoid doing anything wrong. >>> > >>> > A quick superficial search on Stackage Hoogle suggests that adding this >>> > function should create no breakage (4 packages define their own function >>> > called `implies`, none of them import Data.Bool). >>> > >>> > `infix` instead of `infixl` or `infixr` to force you to bracket it; for >>> > the same reason it has the same precedence as `==`. >>> > _______________________________________________ >>> > Libraries mailing list >>> > Libraries at haskell.org >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From david.feuer at gmail.com Mon Jan 18 07:04:39 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 02:04:39 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: I agree with you that not a || b says something a bit different from a `implies` b in a more general logical context. However, I believe that a <= b says exactly the same thing. It's true that it may not be quite obvious to everyone, but anyone thinking enough about logic to *want* an implies function should probably be willing to learn such things. On Mon, Jan 18, 2016 at 1:57 AM, Evan Laforge wrote: > I have only very rarely needed 'implies' and when I do I'm happy with > 'if a then b else False'. But if I needed to do that a lot, I would > write my own function and certainly never use (<=), because I wouldn't > guess that (<=) has the same logic as implies. And even if it does, > isn't the means more important than the end? For the same reason I > wouldn't write 'not a || b' because when I want to say implies I'll > just directly say implies. > > On Mon, Jan 18, 2016 at 11:44 AM, David Feuer wrote: >> I think changing the Ord instance for Bool *may* be the way to go. >> Yes, the lazy one is likely a bit less efficient in some cases, but I >> somehow doubt many are relying on it to be fast. Moreover, people >> expect most Bool operations to short-circuit (I even seem to have lost >> that fight wrt the Data.Bits operations, which I firmly believe should >> be *strict*). >> >> instance Ord Bool where >> False <= _ = True >> True <= x = x >> >> True >= _ = True >> False >= x = not x >> >> False < x = x >> True < _ = False >> >> False > _ = False >> True > x = not x >> >> >> On Mon, Jan 18, 2016 at 12:23 AM, Jon Purdy wrote: >>> +1. ?<=? has the wrong strictness. In ?a `implies` b?, ?b? should not be >>> evaluated if ?a? is false. >>> >>> As a strawman, I?d propose that the Ord instance for Bool be changed?but >>> this is more likely to break existing code, however slightly. >>> >>> On Sun, Jan 17, 2016 at 8:12 PM, David Feuer wrote: >>>> >>>> -1. We already have a `<=` operator. >>>> >>>> On Sun, Jan 17, 2016 at 9:17 PM, Niklas Hamb?chen wrote: >>>> > I propose to add to Data.Bool: >>>> > >>>> > -- | Boolean implication. >>>> > implies :: Bool -> Bool -> Bool >>>> > implies True x = x >>>> > implies False _ = True >>>> > >>>> > infix 4 `implies` -- same as (==) >>>> > >>>> > The request for this is quite old (see e.g. >>>> > >>>> > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html). >>>> > >>>> > I believe that by not trying to use an operator for it, and keeping it >>>> > in Data.Bool, we can avoid doing anything wrong. >>>> > >>>> > A quick superficial search on Stackage Hoogle suggests that adding this >>>> > function should create no breakage (4 packages define their own function >>>> > called `implies`, none of them import Data.Bool). >>>> > >>>> > `infix` instead of `infixl` or `infixr` to force you to bracket it; for >>>> > the same reason it has the same precedence as `==`. >>>> > _______________________________________________ >>>> > Libraries mailing list >>>> > Libraries at haskell.org >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From spam at scientician.net Mon Jan 18 07:19:23 2016 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 18 Jan 2016 08:19:23 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: On 01/18/2016 08:04 AM, David Feuer wrote: > I agree with you that not a || b says something a bit different > from a `implies` b in a more general logical context. However, I > believe that a <= b says exactly the same thing. It's true that it > may not be quite obvious to everyone, but anyone thinking enough about > logic to *want* an implies function should probably be willing to > learn such things. I would think using "<=" would be actively harmful for readers in that the arrow points the wrong way from the usual...? (I realize in this case it's the comparison operator and that conventions may differ, but...) From Andrew.Butterfield at scss.tcd.ie Mon Jan 18 08:50:42 2016 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Mon, 18 Jan 2016 08:50:42 +0000 Subject: Proposal: Data.Bool.implies In-Reply-To: <569C4B48.6060507@nh2.me> References: <569C4B48.6060507@nh2.me> Message-ID: <609E2897-7DF5-4F8E-8971-C7A784E74DA6@scss.tcd.ie> HI Niklas, > On 18 Jan 2016, at 02:17, Niklas Hamb?chen wrote: > > I propose to add to Data.Bool: > > -- | Boolean implication. > implies :: Bool -> Bool -> Bool > implies True x = x > implies False _ = True Fine by me (+1) > > infix 4 `implies` -- same as (==) > > The request for this is quite old (see e.g. > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html). > > I believe that by not trying to use an operator for it, and keeping it > in Data.Bool, we can avoid doing anything wrong. > > A quick superficial search on Stackage Hoogle suggests that adding this > function should create no breakage (4 packages define their own function > called `implies`, none of them import Data.Bool). > > `infix` instead of `infixl` or `infixr` to force you to bracket it; for > the same reason it has the same precedence as `==`. In equational logic, it makes more sense for implication to bind tighter than equivalence, and it would usually be considered as infixr a `implies` b `implies` c same as a `implies` (b `implies` c) But if this breaks something else then plain infix is fine.... That this is the same associativity rule as for function arrows is not a coincidence, by the way. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland From hvriedel at gmail.com Mon Jan 18 09:14:12 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 18 Jan 2016 10:14:12 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: <569C4B48.6060507@nh2.me> ("Niklas \=\?utf-8\?Q\?Hamb\=C3\=BCchen\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Mon, 18 Jan 2016 03:17:44 +0100") References: <569C4B48.6060507@nh2.me> Message-ID: <87egdf1c7v.fsf@gmail.com> On 2016-01-18 at 03:17:44 +0100, Niklas Hamb?chen wrote: [...] > The request for this is quite old (see e.g. > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html). > > I believe that by not trying to use an operator for it, and keeping it > in Data.Bool, we can avoid doing anything wrong. Just wondering, what could/would go wrong if we did use an operator `==>` (still be hidden in Data.Bool[1]), i.e. (==>) :: Bool -> Bool -> Bool True ==> x = x False ==> _ = True this would leave open the option to have an obvious flipped version (<==) :: Bool -> Bool -> Bool (<==) = flip (==>) [1]: Consequently, if `==>` is available only via explicit Data.Bool import, a conflict with QuickCheck's (==>) shouldn't be a big issue IMHO From david.feuer at gmail.com Mon Jan 18 09:21:38 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 04:21:38 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: <87egdf1c7v.fsf@gmail.com> References: <569C4B48.6060507@nh2.me> <87egdf1c7v.fsf@gmail.com> Message-ID: I don't think flipping it is the way to go; I expect things to short-circuit from left to right. On Jan 18, 2016 4:14 AM, "Herbert Valerio Riedel" wrote: > On 2016-01-18 at 03:17:44 +0100, Niklas Hamb?chen wrote: > > [...] > > > The request for this is quite old (see e.g. > > > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html > ). > > > > I believe that by not trying to use an operator for it, and keeping it > > in Data.Bool, we can avoid doing anything wrong. > > Just wondering, what could/would go wrong if we did use an operator > `==>` (still be hidden in Data.Bool[1]), i.e. > > (==>) :: Bool -> Bool -> Bool > True ==> x = x > False ==> _ = True > > > this would leave open the option to have an obvious flipped version > > (<==) :: Bool -> Bool -> Bool > (<==) = flip (==>) > > > > [1]: Consequently, if `==>` is available only via explicit Data.Bool > import, a conflict with QuickCheck's (==>) shouldn't be a big > issue IMHO > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Butterfield at scss.tcd.ie Mon Jan 18 09:26:45 2016 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Mon, 18 Jan 2016 09:26:45 +0000 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> <87egdf1c7v.fsf@gmail.com> Message-ID: <87CEB477-471B-403D-B9A4-11DCB0717AAE@scss.tcd.ie> > On 18 Jan 2016, at 09:21, David Feuer wrote: > > I don't think flipping it is the way to go; I expect things to short-circuit from left to right. > > On Jan 18, 2016 4:14 AM, "Herbert Valerio Riedel" > wrote: > On 2016-01-18 at 03:17:44 +0100, Niklas Hamb?chen wrote: > this would leave open the option to have an obvious flipped version > > (<==) :: Bool -> Bool -> Bool > (<==) = flip (==>) But you can short-circuit this on the left ! F <== p = not p T <== p = T Note quite the same as short circuiting ==> on the left... ;-) Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jan 18 09:27:08 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 10:27:08 +0100 (CET) Subject: Proposal: Data.Bool.implies In-Reply-To: <569C4B48.6060507@nh2.me> References: <569C4B48.6060507@nh2.me> Message-ID: On Mon, 18 Jan 2016, Niklas Hamb?chen wrote: > A quick superficial search on Stackage Hoogle suggests that adding this > function should create no breakage (4 packages define their own function > called `implies`, none of them import Data.Bool). One of it is certainly my: https://hackage.haskell.org/package/utility-ht-0.0.11/docs/Data-Bool-HT.html#v:implies that you can simply import without altering 'base'. From lemming at henning-thielemann.de Mon Jan 18 09:32:15 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 10:32:15 +0100 (CET) Subject: Proposal: Data.Bool.implies In-Reply-To: <609E2897-7DF5-4F8E-8971-C7A784E74DA6@scss.tcd.ie> References: <569C4B48.6060507@nh2.me> <609E2897-7DF5-4F8E-8971-C7A784E74DA6@scss.tcd.ie> Message-ID: On Mon, 18 Jan 2016, Andrew Butterfield wrote: > In equational logic, it makes more sense for implication to bind tighter than equivalence, > and it would usually be considered as infixr > > a `implies` b `implies` c same as a `implies` (b `implies` c) > > But if this breaks something else then plain infix is fine.... > > That this is the same associativity rule as for function arrows is not a coincidence, by the way. It is currying in logic. I assume it was the reason to make 'implies' infixr in utility-ht. From mail at nh2.me Mon Jan 18 13:45:26 2016 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Mon, 18 Jan 2016 14:45:26 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: <569CEC76.8070409@nh2.me> On 18/01/16 05:12, David Feuer wrote: > -1. We already have a `<=` operator. I would actively discourage from using that for implication - it is extremely counter-intuitive, and invites future headlines like "Self Driving Car Crushes Human Because In Haskell Logical Operators Are The Other Way Around" On 18/01/16 06:23, Jon Purdy wrote: > +1. ?<=? has the wrong strictness. In ?a `implies` b?, ?b? should not be > evaluated if ?a? is false. > > As a strawman, I?d propose that the Ord instance for Bool be changed?but > this is more likely to break existing code, however slightly. I think there's simply a difference between comparison and implication. For `<=` the existing strictness makes sense. For implication, a different strictness makes sense. From mail at nh2.me Mon Jan 18 13:57:05 2016 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Mon, 18 Jan 2016 14:57:05 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: <609E2897-7DF5-4F8E-8971-C7A784E74DA6@scss.tcd.ie> References: <569C4B48.6060507@nh2.me> <609E2897-7DF5-4F8E-8971-C7A784E74DA6@scss.tcd.ie> Message-ID: <569CEF31.4050806@nh2.me> On 18/01/16 09:50, Andrew Butterfield wrote: > In equational logic, it makes more sense for implication to bind tighter than equivalence, > and it would usually be considered as infixr > > a `implies` b `implies` c same as a `implies` (b `implies` c) This is a fair point; my reasoning was that when the variables are a bit longer, it can be more difficult for humans to do brain bracketing, that's why I proposed explicit bracketing for multiple implies with plain infix. From mail at joachim-breitner.de Mon Jan 18 15:43:53 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 18 Jan 2016 16:43:53 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: <569C4B48.6060507@nh2.me> References: <569C4B48.6060507@nh2.me> Message-ID: <1453131833.1565.53.camel@joachim-breitner.de> Hi, Am Montag, den 18.01.2016, 03:17 +0100 schrieb Niklas Hamb?chen: > I propose to add to Data.Bool: > > ????-- | Boolean implication. > ????implies :: Bool -> Bool -> Bool > ????implies True??x = x > ????implies False _ = True > > ????infix 4 `implies` -- same as (==) I?m +1 on the grounds that although I know that one of <= or => cuts it, it causes extra mental work to find out which (and annoyance to find out that it is the ?wrong? one). Using a name is explicit and gets it right the first time. -1 on changing the order for Bool, it would just break too much code that relies on that in a fairly obscure way. +1 for making it right-associative, as implications are usually written. Undecided about ==>. It would be nice, but the conflict with quickcheck would be annoying. Leaning towards -1. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From abela at chalmers.se Mon Jan 18 16:27:48 2016 From: abela at chalmers.se (Andreas Abel) Date: Mon, 18 Jan 2016 17:27:48 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: <1453131833.1565.53.camel@joachim-breitner.de> References: <569C4B48.6060507@nh2.me> <1453131833.1565.53.camel@joachim-breitner.de> Message-ID: <569D1284.6070907@chalmers.se> +1 Same opinion as Joachim. --Andreas On 18.01.2016 16:43, Joachim Breitner wrote: > Hi, > > Am Montag, den 18.01.2016, 03:17 +0100 schrieb Niklas Hamb?chen: >> I propose to add to Data.Bool: >> >> -- | Boolean implication. >> implies :: Bool -> Bool -> Bool >> implies True x = x >> implies False _ = True >> >> infix 4 `implies` -- same as (==) > > I?m +1 on the grounds that although I know that one of <= or => cuts > it, it causes extra mental work to find out which (and annoyance to > find out that it is the ?wrong? one). Using a name is explicit and gets > it right the first time. > > -1 on changing the order for Bool, it would just break too much code > that relies on that in a fairly obscure way. > > +1 for making it right-associative, as implications are usually > written. > > Undecided about ==>. It would be nice, but the conflict with quickcheck > would be annoying. Leaning towards -1. > > > Greetings, > Joachim -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From byorgey at gmail.com Mon Jan 18 16:59:31 2016 From: byorgey at gmail.com (Brent Yorgey) Date: Mon, 18 Jan 2016 16:59:31 +0000 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: I disagree. The equivalence between `implies` and (<=) depends on the ordering chosen for Bool, which is completely arbitrary, and is not something people thinking about logic should be expected to know or learn. For example, the Coq standard library happens to choose the other order, with True < False. -Brent On Mon, Jan 18, 2016 at 1:04 AM David Feuer wrote: > I agree with you that not a || b says something a bit different > from a `implies` b in a more general logical context. However, I > believe that a <= b says exactly the same thing. It's true that it > may not be quite obvious to everyone, but anyone thinking enough about > logic to *want* an implies function should probably be willing to > learn such things. > > On Mon, Jan 18, 2016 at 1:57 AM, Evan Laforge wrote: > > I have only very rarely needed 'implies' and when I do I'm happy with > > 'if a then b else False'. But if I needed to do that a lot, I would > > write my own function and certainly never use (<=), because I wouldn't > > guess that (<=) has the same logic as implies. And even if it does, > > isn't the means more important than the end? For the same reason I > > wouldn't write 'not a || b' because when I want to say implies I'll > > just directly say implies. > > > > On Mon, Jan 18, 2016 at 11:44 AM, David Feuer > wrote: > >> I think changing the Ord instance for Bool *may* be the way to go. > >> Yes, the lazy one is likely a bit less efficient in some cases, but I > >> somehow doubt many are relying on it to be fast. Moreover, people > >> expect most Bool operations to short-circuit (I even seem to have lost > >> that fight wrt the Data.Bits operations, which I firmly believe should > >> be *strict*). > >> > >> instance Ord Bool where > >> False <= _ = True > >> True <= x = x > >> > >> True >= _ = True > >> False >= x = not x > >> > >> False < x = x > >> True < _ = False > >> > >> False > _ = False > >> True > x = not x > >> > >> > >> On Mon, Jan 18, 2016 at 12:23 AM, Jon Purdy > wrote: > >>> +1. ?<=? has the wrong strictness. In ?a `implies` b?, ?b? should not > be > >>> evaluated if ?a? is false. > >>> > >>> As a strawman, I?d propose that the Ord instance for Bool be > changed?but > >>> this is more likely to break existing code, however slightly. > >>> > >>> On Sun, Jan 17, 2016 at 8:12 PM, David Feuer > wrote: > >>>> > >>>> -1. We already have a `<=` operator. > >>>> > >>>> On Sun, Jan 17, 2016 at 9:17 PM, Niklas Hamb?chen > wrote: > >>>> > I propose to add to Data.Bool: > >>>> > > >>>> > -- | Boolean implication. > >>>> > implies :: Bool -> Bool -> Bool > >>>> > implies True x = x > >>>> > implies False _ = True > >>>> > > >>>> > infix 4 `implies` -- same as (==) > >>>> > > >>>> > The request for this is quite old (see e.g. > >>>> > > >>>> > > http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html > ). > >>>> > > >>>> > I believe that by not trying to use an operator for it, and keeping > it > >>>> > in Data.Bool, we can avoid doing anything wrong. > >>>> > > >>>> > A quick superficial search on Stackage Hoogle suggests that adding > this > >>>> > function should create no breakage (4 packages define their own > function > >>>> > called `implies`, none of them import Data.Bool). > >>>> > > >>>> > `infix` instead of `infixl` or `infixr` to force you to bracket it; > for > >>>> > the same reason it has the same precedence as `==`. > >>>> > _______________________________________________ > >>>> > Libraries mailing list > >>>> > Libraries at haskell.org > >>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>> _______________________________________________ > >>>> Libraries mailing list > >>>> Libraries at haskell.org > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>> > >>> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jan 18 18:38:01 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 19:38:01 +0100 (CET) Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: On Mon, 18 Jan 2016, Brent Yorgey wrote: > I disagree.? The equivalence between `implies` and (<=) depends on the > ordering chosen for Bool, which is completely arbitrary, and is not > something people thinking about logic should be expected to know or > learn.? For example, the Coq standard library happens to choose the > other order, with True < False. I can confirm that the order is arbitrary. I used a Modula II implementation where True was represented as -1, because that is the bit pattern where all bits are set. From david.feuer at gmail.com Mon Jan 18 20:10:07 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 15:10:07 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples Message-ID: For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that fmap (+1) (1,2,3) doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following: instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc. I would really love to see these make 8.0.0, but if that's impossible then so be it. From ryan.gl.scott at gmail.com Mon Jan 18 20:16:25 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 15:16:25 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples Message-ID: Strong +1 from me. We derive Eq/Ord/Read/Show/etc. for all tuple types of size up to 15 as it is, we might as well do the same for Functor. (Personally, I'd even argue for adding Foldable and Traversable instances as well, but the Foldable instance for pairs has proven to be pretty controversial...) Ryan S. From david.feuer at gmail.com Mon Jan 18 20:20:06 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 15:20:06 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: I'd be strongly +1 on that too! Traversable is strong magic. On Mon, Jan 18, 2016 at 3:16 PM, Ryan Scott wrote: > Strong +1 from me. We derive Eq/Ord/Read/Show/etc. for all tuple types > of size up to 15 as it is, we might as well do the same for Functor. > > (Personally, I'd even argue for adding Foldable and Traversable > instances as well, but the Foldable instance for pairs has proven to > be pretty controversial...) > > Ryan S. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From lemming at henning-thielemann.de Mon Jan 18 20:32:13 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 21:32:13 +0100 (CET) Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: On Mon, 18 Jan 2016, David Feuer wrote: > I'd be strongly +1 on that too! Traversable is strong magic. I am opposed to all these Functor, Foldable, Traversable stuff on tuples (including pairs). Why should the last element of a tuple get a special treatment? I suspect that if you use such instances you are making something dirty. I am afraid that those instance may hide type errors or make type errors incomprehensible. E.g. if you get a stack of fmap's wrong, you do not get a "no instance for Functor ((,) a)" but instead the type mismatch occurs at a different level. I would never use such an instance. Can I be warned if I accidentally use it anyway? From david.feuer at gmail.com Mon Jan 18 20:37:38 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 15:37:38 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: Actually, I currently get a much worse error message: Prelude> fmap (+1) (1,2,3) :2:1: Non type-variable argument in the constraint: Functor ((,,) t t) (Use FlexibleContexts to permit this) When checking that ?it? has the inferred type it :: forall b t t1. (Functor ((,,) t t1), Num b, Num t, Num t1) => (t, t1, b) That there is a *lousy* error message. I understand that there are newcomers who struggle to understand the difference between tuples and lists; I don't think that's a good enough reason to omit a good and valid instance. On Mon, Jan 18, 2016 at 3:32 PM, Henning Thielemann wrote: > > On Mon, 18 Jan 2016, David Feuer wrote: > >> I'd be strongly +1 on that too! Traversable is strong magic. > > > I am opposed to all these Functor, Foldable, Traversable stuff on tuples > (including pairs). Why should the last element of a tuple get a special > treatment? I suspect that if you use such instances you are making something > dirty. I am afraid that those instance may hide type errors or make type > errors incomprehensible. E.g. if you get a stack of fmap's wrong, you do not > get a "no instance for Functor ((,) a)" but instead the type mismatch occurs > at a different level. > > I would never use such an instance. Can I be warned if I accidentally use it > anyway? From lemming at henning-thielemann.de Mon Jan 18 20:42:34 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 21:42:34 +0100 (CET) Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: On Mon, 18 Jan 2016, David Feuer wrote: > Actually, I currently get a much worse error message: > > Prelude> fmap (+1) (1,2,3) > > :2:1: > Non type-variable argument in the constraint: Functor ((,,) t t) > (Use FlexibleContexts to permit this) > When checking that ?it? has the inferred type > it :: forall b t t1. > (Functor ((,,) t t1), Num b, Num t, Num t1) => > (t, t1, b) > > That there is a *lousy* error message. indeed > I understand that there are newcomers who struggle to understand the > difference between tuples and lists; I don't think that's a good > enough reason to omit a good and valid instance. I would not qualify myself as a newcomer. For me these instances are a problem, not a help. From cma at bitemyapp.com Mon Jan 18 20:44:33 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 18 Jan 2016 14:44:33 -0600 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: I've addressed this here: http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html The thousand-papercuts opposition to typeclass instances on the premise that a Functor for (a, b, c) maps over the final type not making sense is a rejection of how higher kinded types and typeclasses work together. This is natural and predictable if one bothers to explain it. On Mon, Jan 18, 2016 at 2:42 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 18 Jan 2016, David Feuer wrote: > > Actually, I currently get a much worse error message: >> >> Prelude> fmap (+1) (1,2,3) >> >> :2:1: >> Non type-variable argument in the constraint: Functor ((,,) t t) >> (Use FlexibleContexts to permit this) >> When checking that ?it? has the inferred type >> it :: forall b t t1. >> (Functor ((,,) t t1), Num b, Num t, Num t1) => >> (t, t1, b) >> >> That there is a *lousy* error message. >> > > indeed > > > I understand that there are newcomers who struggle to understand the >> difference between tuples and lists; I don't think that's a good >> enough reason to omit a good and valid instance. >> > > I would not qualify myself as a newcomer. For me these instances are a > problem, not a help. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Mon Jan 18 20:46:20 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 15:46:20 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: A surprising amount has already been written on the topic of Functor/Foldable/Traversable instances (both for and against) for tuples, so I feel it's fair to link them here: * FTP dangers: http://nattermorphisms.blogspot.com/2015/02/ftp-dangers.html * Either and (,) in Haskell are not arbitrary: http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html * Foldable for non-Haskellers: Haskell's controversial FTP proposal: http://tojans.me/blog/2015/10/13/foldable-for-non-haskellers-haskells-controversial-ftp-proposal/#update:916dcbca10117e99a7571170d02b3db4 * The Not-A-Wat in Haskell: https://www.youtube.com/watch?v=87re_yIQMDw&feature=youtu.be Ryan S. On Mon, Jan 18, 2016 at 3:44 PM, Christopher Allen wrote: > I've addressed this here: > > http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html > > The thousand-papercuts opposition to typeclass instances on the premise that > a Functor for (a, b, c) maps over the final type not making sense is a > rejection of how higher kinded types and typeclasses work together. This is > natural and predictable if one bothers to explain it. > > > On Mon, Jan 18, 2016 at 2:42 PM, Henning Thielemann > wrote: >> >> >> On Mon, 18 Jan 2016, David Feuer wrote: >> >>> Actually, I currently get a much worse error message: >>> >>> Prelude> fmap (+1) (1,2,3) >>> >>> :2:1: >>> Non type-variable argument in the constraint: Functor ((,,) t t) >>> (Use FlexibleContexts to permit this) >>> When checking that ?it? has the inferred type >>> it :: forall b t t1. >>> (Functor ((,,) t t1), Num b, Num t, Num t1) => >>> (t, t1, b) >>> >>> That there is a *lousy* error message. >> >> >> indeed >> >> >>> I understand that there are newcomers who struggle to understand the >>> difference between tuples and lists; I don't think that's a good >>> enough reason to omit a good and valid instance. >> >> >> I would not qualify myself as a newcomer. For me these instances are a >> problem, not a help. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > -- > Chris Allen > Currently working on http://haskellbook.com From johnw at newartisans.com Mon Jan 18 20:58:47 2016 From: johnw at newartisans.com (John Wiegley) Date: Mon, 18 Jan 2016 12:58:47 -0800 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: (Henning Thielemann's message of "Mon, 18 Jan 2016 21:32:13 +0100 (CET)") References: Message-ID: >>>>> Henning Thielemann writes: > I would never use such an instance. Can I be warned if I accidentally use it > anyway? I don't know why "I wouldn't use it" should extend to "it shouldn't exist". +1 on having such instances. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From eric at seidel.io Mon Jan 18 20:59:08 2016 From: eric at seidel.io (Eric Seidel) Date: Mon, 18 Jan 2016 12:59:08 -0800 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: <1453150748.323533.495630730.20735479@webmail.messagingengine.com> On Mon, Jan 18, 2016, at 12:44, Christopher Allen wrote: > I've addressed this here: > > http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html > > The thousand-papercuts opposition to typeclass instances on the premise > that a Functor for (a, b, c) maps over the final type not making sense is a > rejection of how higher kinded types and typeclasses work together. This > is natural and predictable if one bothers to explain it. The behavior is indeed predictable, but I think Henning is arguing (and I would agree) that it is *undesirable*. That being said, I think the ship has sailed on the "should tuples be a Functor/etc" discussion. The current proposal is aimed at making the set of available instances more consistent across tuples, which I'd argue is a good thing regardless of one's position on the specific class. From amindfv at gmail.com Mon Jan 18 21:17:39 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 18 Jan 2016 16:17:39 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <1453150748.323533.495630730.20735479@webmail.messagingengine.com> References: <1453150748.323533.495630730.20735479@webmail.messagingengine.com> Message-ID: I share Henning's concerns. Can someone provide a realistic example of where an instance for (,,) or (,,,) *is* desirable? Tom > El 18 ene 2016, a las 15:59, Eric Seidel escribi?: > >> On Mon, Jan 18, 2016, at 12:44, Christopher Allen wrote: >> I've addressed this here: >> >> http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html >> >> The thousand-papercuts opposition to typeclass instances on the premise >> that a Functor for (a, b, c) maps over the final type not making sense is a >> rejection of how higher kinded types and typeclasses work together. This >> is natural and predictable if one bothers to explain it. > > The behavior is indeed predictable, but I think Henning is arguing (and > I would agree) that it is *undesirable*. > > That being said, I think the ship has sailed on the "should tuples be a > Functor/etc" discussion. The current proposal is aimed at making the set > of available instances more consistent across tuples, which I'd argue is > a good thing regardless of one's position on the specific class. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From tikhon at jelv.is Mon Jan 18 21:20:59 2016 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 18 Jan 2016 13:20:59 -0800 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <1453150748.323533.495630730.20735479@webmail.messagingengine.com> References: <1453150748.323533.495630730.20735479@webmail.messagingengine.com> Message-ID: > I don't know why "I wouldn't use it" should extend to "it shouldn't exist". I'm in favor of these instances, if only for the sake of consistency. However, I don't agree with this reasoning. Typeclass instances in Haskell are an inherently global construct: once an instance is defined, you can't do anything about it. You can't replace it or redefine it or even not import it. At the same time, it affects type inference and type error messages even if you're *not* using it. As a slightly more extreme example, there's a reason we don't have a Num instance for functions or Applicatives by default: while perfectly well-formed and even useful, having these instances would lead to worse error messages or even code typechecking when it shouldn't with weird results?even if you never rely on them yourself. On Mon, Jan 18, 2016 at 12:59 PM, Eric Seidel wrote: > On Mon, Jan 18, 2016, at 12:44, Christopher Allen wrote: > > I've addressed this here: > > > > http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html > > > > The thousand-papercuts opposition to typeclass instances on the premise > > that a Functor for (a, b, c) maps over the final type not making sense > is a > > rejection of how higher kinded types and typeclasses work together. This > > is natural and predictable if one bothers to explain it. > > The behavior is indeed predictable, but I think Henning is arguing (and > I would agree) that it is *undesirable*. > > That being said, I think the ship has sailed on the "should tuples be a > Functor/etc" discussion. The current proposal is aimed at making the set > of available instances more consistent across tuples, which I'd argue is > a good thing regardless of one's position on the specific class. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Jan 18 21:22:12 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 22:22:12 +0100 (CET) Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: On Mon, 18 Jan 2016, John Wiegley wrote: >>>>>> Henning Thielemann writes: > >> I would never use such an instance. Can I be warned if I accidentally use it >> anyway? > > I don't know why "I wouldn't use it" should extend to "it shouldn't exist". Because I cannot turn it off and I cannot get warning. It is inserted by GHC whenever it matches, even if I made a mistake when programming. From ryan.gl.scott at gmail.com Mon Jan 18 21:29:41 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 16:29:41 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: I can sympathize with your sentiment. Normally, if there's a datatype whose instance I don't want to use, I just make my own replacement. However, it's hard to do that with tuples given their special syntactic treatment. It might be worth looking into adding RebindableSyntax for tuples [1] to address scenarios like this. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/7845 On Mon, Jan 18, 2016 at 4:22 PM, Henning Thielemann wrote: > > On Mon, 18 Jan 2016, John Wiegley wrote: > >>>>>>> Henning Thielemann writes: >> >> >>> I would never use such an instance. Can I be warned if I accidentally use >>> it >>> anyway? >> >> >> I don't know why "I wouldn't use it" should extend to "it shouldn't >> exist". > > > Because I cannot turn it off and I cannot get warning. It is inserted by GHC > whenever it matches, even if I made a mistake when programming. From eric at seidel.io Mon Jan 18 21:31:13 2016 From: eric at seidel.io (Eric Seidel) Date: Mon, 18 Jan 2016 13:31:13 -0800 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: <1453152673.330244.495675890.0D6D4880@webmail.messagingengine.com> On Mon, Jan 18, 2016, at 13:22, Henning Thielemann wrote: > > On Mon, 18 Jan 2016, John Wiegley wrote: > > >>>>>> Henning Thielemann writes: > > > >> I would never use such an instance. Can I be warned if I accidentally use it > >> anyway? > > > > I don't know why "I wouldn't use it" should extend to "it shouldn't exist". > > Because I cannot turn it off and I cannot get warning. It is inserted by > GHC whenever it matches, even if I made a mistake when programming. There may be an easier way, but one could write a Core-to-Core plugin that kills the build if it sees an expression like `fmap @(,)`. From ryan.gl.scott at gmail.com Mon Jan 18 21:46:34 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 16:46:34 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples Message-ID: Edward Kmett outlines his reasons why he finds instances for (,) useful here: https://www.reddit.com/r/haskell/comments/3pfg7x/either_and_in_haskell_are_not_arbitrary/cw65ck2 Speaking for myself, I find the Traversable instance for (,) incredibly useful. It's quite nice to build up a list of results alongside a state (i.e, (state, [result]) ), and then traverse over each of the results such that the new results each have their own copy of the state (i.e., [(state, result)] ). That kind of patterns arises quite often in lensy code, and the Traversable instance for (,) is perfect for the job. Right now, if you want to have two different states, you have to employ a kludge (something like ((state1, state2), [result]) ) to get around the fact that there's no Traversable instance for (,,), (,,,), etc. Ryan S. From johnw at newartisans.com Mon Jan 18 21:46:58 2016 From: johnw at newartisans.com (John Wiegley) Date: Mon, 18 Jan 2016 13:46:58 -0800 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: (Henning Thielemann's message of "Mon, 18 Jan 2016 22:22:12 +0100 (CET)") References: Message-ID: >>>>> Henning Thielemann writes: > Because I cannot turn it off and I cannot get warning. It is inserted by GHC > whenever it matches, even if I made a mistake when programming. OK, that's a pretty sound argument against, since this could affect everyone everywhere, and not just those who opt-in. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From lemming at henning-thielemann.de Mon Jan 18 21:50:15 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 22:50:15 +0100 (CET) Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: On Mon, 18 Jan 2016, Ryan Scott wrote: > Edward Kmett outlines his reasons why he finds instances for (,) > useful here: https://www.reddit.com/r/haskell/comments/3pfg7x/either_and_in_haskell_are_not_arbitrary/cw65ck2 > > Speaking for myself, I find the Traversable instance for (,) > incredibly useful. It's quite nice to build up a list of results > alongside a state (i.e, (state, [result]) ), and then traverse over > each of the results such that the new results each have their own copy > of the state (i.e., [(state, result)] ). That kind of patterns arises > quite often in lensy code, and the Traversable instance for (,) is > perfect for the job. Sounds like a nice application of the Writer monad, doesn't it? "Writer" would be much more explicit about what you want to achieve. From ryan.gl.scott at gmail.com Mon Jan 18 21:58:55 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 16:58:55 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: WriterT (and Writer) don't quite capture what I need. With WriterT, you have to tack on that extra m type parameter, and when you just specialize it to Identity, it only serves as an extra hoop to jump through to dig out the state. The prescence of the m type parameter also prevents me from easily modifying the state with a Bifunctor instance, whereas tuples have no such obstacle. It's a minor difference, but an important one when I decide which data structure to reach for. Ryan S. From lemming at henning-thielemann.de Mon Jan 18 22:10:46 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 18 Jan 2016 23:10:46 +0100 (CET) Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: On Mon, 18 Jan 2016, Ryan Scott wrote: > WriterT (and Writer) don't quite capture what I need. With WriterT, > you have to tack on that extra m type parameter, and when you just > specialize it to Identity, it only serves as an extra hoop to jump > through to dig out the state. The prescence of the m type parameter > also prevents me from easily modifying the state with a Bifunctor > instance, whereas tuples have no such obstacle. Is it important to achieve this with Bifunctor functions? You could write a state changing function, or add it to 'transformers', or define your own Writer as an independent type like it was in mtl initially. > It's a minor difference, but an important one when I decide which data > structure to reach for. Sure, but if you want a certain behaviour then a custom type is better than putting so much overloading to a standard (tuple) type, isn't it? From ryan.gl.scott at gmail.com Mon Jan 18 22:22:40 2016 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Mon, 18 Jan 2016 17:22:40 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: > Is it important to achieve this with Bifunctor functions? You could write a state changing function, or add it to 'transformers', or define your own Writer as an independent type like it was in mtl initially. For my use case, where I'm writing highly polymorphic code that needs to be able to work over several datatypes with two type parameters, using Bifunctor is quite less cumbersome than manually crafting individual functions tailored to each individual data structure. And while I certainly could define my own replacements for every single tuple type, it feels a bit silly doing so when the perfect datatypes are sitting right in front of me. > Sure, but if you want a certain behaviour then a custom type is better than putting so much overloading to a standard (tuple) type, isn't it? The phrase "custom behavior" is a bit confusing to me, since there's literally only one law-abiding Functor and Traversable instance for any tuple type (and the Foldable implementation falls out from that). These instances aren't custom behavior, they're the only behavior they can have in this context. And I certainly don't view tuple instances as being "overloaded". IMO, their instances are quite well though-out consequences of their structure. When you're parametrically polymorphic in the last type parameter of a tuple, the operations you can perform on it are what the Functor and Traversable instances so nicely give you. Ryan S. On Mon, Jan 18, 2016 at 5:10 PM, Henning Thielemann wrote: > > On Mon, 18 Jan 2016, Ryan Scott wrote: > >> WriterT (and Writer) don't quite capture what I need. With WriterT, >> you have to tack on that extra m type parameter, and when you just >> specialize it to Identity, it only serves as an extra hoop to jump >> through to dig out the state. The prescence of the m type parameter >> also prevents me from easily modifying the state with a Bifunctor >> instance, whereas tuples have no such obstacle. > > > Is it important to achieve this with Bifunctor functions? You could write a > state changing function, or add it to 'transformers', or define your own > Writer as an independent type like it was in mtl initially. > >> It's a minor difference, but an important one when I decide which data >> structure to reach for. > > > Sure, but if you want a certain behaviour then a custom type is better than > putting so much overloading to a standard (tuple) type, isn't it? From david.feuer at gmail.com Mon Jan 18 23:04:40 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 18:04:40 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <1453150748.323533.495630730.20735479@webmail.messagingengine.com> Message-ID: In every case I can think of where an instance turned out to be a problem, that was because there were multiple law-abiding options and the designers chose the wrong one. Examples that at least some people disagree with: instance Monoid a => Monoid (Maybe a) -- McBride has argued for mappend = (<|>) here instead. instance Monoid b => Monoid (a -> b) -- McBride again, IIRC, dislikes this, weakly preferring -- instance a ~ b => Monoid (a -> b) instance (Eq k, Hashable k) => Monoid (HashMap k v) -- Almost everyone wants -- instance (Semigroup v, Hashable k) => Monoid (HashMap k v) A Num instance for functions is a bad idea because it leads to terrible error messages, but I would argue that's a poor example. The (->) constructor has a sufficiently special, and sufficiently silent, role in the language that it requires a *uniquely* high level of care. When that care is taken (as with the Monad ((->) a) instance), things generally work out just fine. On Jan 18, 2016 4:21 PM, "Tikhon Jelvis" wrote: > > I don't know why "I wouldn't use it" should extend to "it shouldn't > exist". > > I'm in favor of these instances, if only for the sake of consistency. > However, I don't agree with this reasoning. Typeclass instances in Haskell > are an inherently global construct: once an instance is defined, you can't > do anything about it. You can't replace it or redefine it or even not > import it. At the same time, it affects type inference and type error > messages even if you're *not* using it. > > As a slightly more extreme example, there's a reason we don't have a Num > instance for functions or Applicatives by default: while perfectly > well-formed and even useful, having these instances would lead to worse > error messages or even code typechecking when it shouldn't with weird > results?even if you never rely on them yourself. > > On Mon, Jan 18, 2016 at 12:59 PM, Eric Seidel wrote: > >> On Mon, Jan 18, 2016, at 12:44, Christopher Allen wrote: >> > I've addressed this here: >> > >> > http://bitemyapp.com/posts/2015-10-19-either-is-not-arbitrary.html >> > >> > The thousand-papercuts opposition to typeclass instances on the premise >> > that a Functor for (a, b, c) maps over the final type not making sense >> is a >> > rejection of how higher kinded types and typeclasses work together. This >> > is natural and predictable if one bothers to explain it. >> >> The behavior is indeed predictable, but I think Henning is arguing (and >> I would agree) that it is *undesirable*. >> >> That being said, I think the ship has sailed on the "should tuples be a >> Functor/etc" discussion. The current proposal is aimed at making the set >> of available instances more consistent across tuples, which I'd argue is >> a good thing regardless of one's position on the specific class. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Jan 18 23:19:05 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 18 Jan 2016 18:19:05 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <1453152673.330244.495675890.0D6D4880@webmail.messagingengine.com> References: <1453152673.330244.495675890.0D6D4880@webmail.messagingengine.com> Message-ID: I love the idea of adding support for such a warning, but I think core2core is likely too late to do the job properly. The instance resolution information is (currently, at least) thrown out altogether once the type checker finishes its job. And even the slightest bit of inlining of external modules could give false positives. I would think the easiest way would be to add a "suppressed instance" structure to the type checker. It would basically be a stripped-down analogue of the big instance database the type checker uses for instance resolution. When resolving an instance, the type checker would first check the suppressed instance set for it; if it found it there, it would fail or warn as appropriate. So I could write something like {-# SuppressInstance Functor ((,) a) #-} But I could also write something more subtle like {-# WarnInstance Semigroup v => Monoid (HashMap k v) #-} which would only warn me if I use the Monoid instance for a HashMap whose values form a semigroup. On Jan 18, 2016 4:31 PM, "Eric Seidel" wrote: > On Mon, Jan 18, 2016, at 13:22, Henning Thielemann wrote: > > > > On Mon, 18 Jan 2016, John Wiegley wrote: > > > > >>>>>> Henning Thielemann writes: > > > > > >> I would never use such an instance. Can I be warned if I accidentally > use it > > >> anyway? > > > > > > I don't know why "I wouldn't use it" should extend to "it shouldn't > exist". > > > > Because I cannot turn it off and I cannot get warning. It is inserted by > > GHC whenever it matches, even if I made a mistake when programming. > > There may be an easier way, but one could write a Core-to-Core plugin > that kills the build if it sees an expression like `fmap @(,)`. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Mon Jan 18 23:31:32 2016 From: eric at seidel.io (Eric Seidel) Date: Mon, 18 Jan 2016 15:31:32 -0800 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <1453152673.330244.495675890.0D6D4880@webmail.messagingengine.com> Message-ID: <1453159892.357160.495773794.4E2BBFE6@webmail.messagingengine.com> On Mon, Jan 18, 2016, at 15:19, David Feuer wrote: > I love the idea of adding support for such a warning, but I think > core2core > is likely too late to do the job properly. The instance resolution > information is (currently, at least) thrown out altogether once the type > checker finishes its job. And even the slightest bit of inlining of > external modules could give false positives. This was my main concern as well. I don't recall if ghc performs any inlining before running the core2core pipeline, but it's certainly fragile even wrt the pipeline order. > I would think the easiest > way > would be to add a "suppressed instance" structure to the type checker. It > would basically be a stripped-down analogue of the big instance database > the type checker uses for instance resolution. When resolving an > instance, > the type checker would first check the suppressed instance set for it; if > it found it there, it would fail or warn as appropriate. So I could write > something like > > {-# SuppressInstance Functor ((,) a) #-} > > But I could also write something more subtle like > > {-# WarnInstance Semigroup v => Monoid (HashMap k v) #-} > > which would only warn me if I use the Monoid instance for a HashMap whose > values form a semigroup. We might be able to make this work as a type-checker plugin (which would be quite nice at least for experimentation). I don't recall off the top of my head if the constraint solver calls plugins before or after it tries to discharge the constraints on its own, but if plugins get access to constraints first we could write one that simply marks undesired instances as insoluble. From eric at seidel.io Mon Jan 18 23:41:05 2016 From: eric at seidel.io (Eric Seidel) Date: Mon, 18 Jan 2016 15:41:05 -0800 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <1453159892.357160.495773794.4E2BBFE6@webmail.messagingengine.com> References: <1453152673.330244.495675890.0D6D4880@webmail.messagingengine.com> <1453159892.357160.495773794.4E2BBFE6@webmail.messagingengine.com> Message-ID: <1453160465.358766.495778962.6EAE5CDD@webmail.messagingengine.com> On Mon, Jan 18, 2016, at 15:31, Eric Seidel wrote: > > On Mon, Jan 18, 2016, at 15:19, David Feuer wrote: > > I would think the easiest > > way > > would be to add a "suppressed instance" structure to the type checker. It > > would basically be a stripped-down analogue of the big instance database > > the type checker uses for instance resolution. When resolving an > > instance, > > the type checker would first check the suppressed instance set for it; if > > it found it there, it would fail or warn as appropriate. So I could write > > something like > > > > {-# SuppressInstance Functor ((,) a) #-} > > > > But I could also write something more subtle like > > > > {-# WarnInstance Semigroup v => Monoid (HashMap k v) #-} > > > > which would only warn me if I use the Monoid instance for a HashMap whose > > values form a semigroup. > > We might be able to make this work as a type-checker plugin (which would > be quite nice at least for experimentation). I don't recall off the top > of my head if the constraint solver calls plugins before or after it > tries to discharge the constraints on its own, but if plugins get access > to constraints first we could write one that simply marks undesired > instances as insoluble. Ah, plugins are run after the built-in solver, bummer. From abela at chalmers.se Tue Jan 19 07:41:25 2016 From: abela at chalmers.se (Andreas Abel) Date: Tue, 19 Jan 2016 08:41:25 +0100 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: <569DE8A5.8060201@chalmers.se> -1 from me. First, I think people should be discouraged from using tuples. Tuples for anything but very short-lived structures (like returning multiple results from a function) make code very unmaintainable. Instead hand-rolled records are the tool of choice, for which you can define your functor instance as you see fit. Second, it is confusing that fmap (+1) (1,2,3) = (1,2,4) while fmap (+1) [1,2,3] = [2,3,4] --Andreas On 18.01.2016 21:10, David Feuer wrote: > For some reason I really can't imagine, it seems the only tuple type > with a Functor instance is (,) a. I was astonished to find that > > fmap (+1) (1,2,3) > > doesn't work. Since this is *useful*, and there is *only one way to do > it*, I propose we add the following: > > instance Functor ((,,) a b) where > fmap f (a,b,c) = (a,b,f c) > instance Functor ((,,,) a b c) where > fmap f (a,b,c,d) = (a,b,c,f d) > etc. > > I would really love to see these make 8.0.0, but if that's impossible > then so be it. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www2.tcs.ifi.lmu.de/~abel/ From hvriedel at gmail.com Tue Jan 19 08:20:58 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Tue, 19 Jan 2016 09:20:58 +0100 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: (David Feuer's message of "Mon, 18 Jan 2016 15:10:07 -0500") References: Message-ID: <87oacic74l.fsf@gmail.com> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: > For some reason I really can't imagine, it seems the only tuple type > with a Functor instance is (,) a. I was astonished to find that > > fmap (+1) (1,2,3) > > doesn't work. Since this is *useful*, and there is *only one way to do > it*, I propose we add the following: > > instance Functor ((,,) a b) where > fmap f (a,b,c) = (a,b,f c) > instance Functor ((,,,) a b c) where > fmap f (a,b,c,d) = (a,b,c,f d) > etc. As stated elsewhere in this thread already, there is the issue about consistency. Here's a relevant section from the Haskell 2010 report[1]: > 6.1.4 Tuples > > ... > > However, every Haskell implementation must support tuples up to size > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. IMO, we either have no `Functor` instances for tuples at all, or we have them for all tuples up to size 15. The current situations of having them defined only for 2-tuples is inconsistent. Cheers, hvr [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 From carter.schonwald at gmail.com Tue Jan 19 12:30:09 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 19 Jan 2016 07:30:09 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <87oacic74l.fsf@gmail.com> References: <87oacic74l.fsf@gmail.com> Message-ID: Agreed. +1 On Tuesday, January 19, 2016, Herbert Valerio Riedel wrote: > On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: > > For some reason I really can't imagine, it seems the only tuple type > > with a Functor instance is (,) a. I was astonished to find that > > > > fmap (+1) (1,2,3) > > > > doesn't work. Since this is *useful*, and there is *only one way to do > > it*, I propose we add the following: > > > > instance Functor ((,,) a b) where > > fmap f (a,b,c) = (a,b,f c) > > instance Functor ((,,,) a b c) where > > fmap f (a,b,c,d) = (a,b,c,f d) > > etc. > > As stated elsewhere in this thread already, there is the issue about > consistency. Here's a relevant section from the Haskell 2010 report[1]: > > > 6.1.4 Tuples > > > > ... > > > > However, every Haskell implementation must support tuples up to size > > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. > > IMO, we either have no `Functor` instances for tuples at all, or we have > them for all tuples up to size 15. The current situations of having them > defined only for 2-tuples is inconsistent. > > > Cheers, > hvr > > [1]: > https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Jan 19 14:38:22 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 19 Jan 2016 09:38:22 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: Message-ID: +1 from me. We routinely supply instances for tuples of up to 4 or 5 elements elsewhere. There is no need to be randomly inconsistent here. -Edward On Mon, Jan 18, 2016 at 3:10 PM, David Feuer wrote: > For some reason I really can't imagine, it seems the only tuple type > with a Functor instance is (,) a. I was astonished to find that > > fmap (+1) (1,2,3) > > doesn't work. Since this is *useful*, and there is *only one way to do > it*, I propose we add the following: > > instance Functor ((,,) a b) where > fmap f (a,b,c) = (a,b,f c) > instance Functor ((,,,) a b c) where > fmap f (a,b,c,d) = (a,b,c,f d) > etc. > > I would really love to see these make 8.0.0, but if that's impossible > then so be it. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Tue Jan 19 15:24:29 2016 From: alois.cochard at gmail.com (Alois Cochard) Date: Tue, 19 Jan 2016 16:24:29 +0100 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <87oacic74l.fsf@gmail.com> References: <87oacic74l.fsf@gmail.com> Message-ID: +1 Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers). On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote: > On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: > > For some reason I really can't imagine, it seems the only tuple type > > with a Functor instance is (,) a. I was astonished to find that > > > > fmap (+1) (1,2,3) > > > > doesn't work. Since this is *useful*, and there is *only one way to do > > it*, I propose we add the following: > > > > instance Functor ((,,) a b) where > > fmap f (a,b,c) = (a,b,f c) > > instance Functor ((,,,) a b c) where > > fmap f (a,b,c,d) = (a,b,c,f d) > > etc. > > As stated elsewhere in this thread already, there is the issue about > consistency. Here's a relevant section from the Haskell 2010 report[1]: > > > 6.1.4 Tuples > > > > ... > > > > However, every Haskell implementation must support tuples up to size > > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. > > IMO, we either have no `Functor` instances for tuples at all, or we have > them for all tuples up to size 15. The current situations of having them > defined only for 2-tuples is inconsistent. > > > Cheers, > hvr > > [1]: > https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Butterfield at scss.tcd.ie Tue Jan 19 15:46:26 2016 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Tue, 19 Jan 2016 15:46:26 +0000 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> Message-ID: <47D18090-F1D8-40F6-8F38-6FD56F63AB04@scss.tcd.ie> Of course, the proper/correct "implementation" for "Functor" with tuples should be instance Functor (,) where fmap (f,g) (a,b) = (f a, g b) instance Functor (,,) where fmap (f,g,h) (a,b) = (f a, g b, h c) instance Functor (,,,) where fmap (f,g,h,k) (a,b) = (f a, g b, h c, k d) and so on... (where fmap's type sig alters in a "tuple-structured" way with each instance...) The current instance for (,)a is my fmap(id, f) Or should we have 15 classes ? class Functor... class BiFunctor... class TriFunctor.... ... class QuincadecaFunctor /PentadecaFunctor - depending if you prefer Latin/Greek ;-) This probably doesn't clear anything up but does explain why heavy tuple use is deprecated as per an earlier mail in this thread..... Regards, Andrew > On 19 Jan 2016, at 12:30, Carter Schonwald wrote: > > Agreed. +1 > > On Tuesday, January 19, 2016, Herbert Valerio Riedel > wrote: > On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: > > For some reason I really can't imagine, it seems the only tuple type > > with a Functor instance is (,) a. I was astonished to find that > > > > fmap (+1) (1,2,3) > > > > doesn't work. Since this is *useful*, and there is *only one way to do > > it*, I propose we add the following: > > > > instance Functor ((,,) a b) where > > fmap f (a,b,c) = (a,b,f c) > > instance Functor ((,,,) a b c) where > > fmap f (a,b,c,d) = (a,b,c,f d) > > etc. > > As stated elsewhere in this thread already, there is the issue about > consistency. Here's a relevant section from the Haskell 2010 report[1]: > > > 6.1.4 Tuples > > > > ... > > > > However, every Haskell implementation must support tuples up to size > > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. > > IMO, we either have no `Functor` instances for tuples at all, or we have > them for all tuples up to size 15. The current situations of having them > defined only for 2-tuples is inconsistent. > > > Cheers, > hvr > > [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Jan 19 16:55:17 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 19 Jan 2016 11:55:17 -0500 Subject: Add traverseWithIndex to Data.Sequence Message-ID: Indexed traversals seem to be pretty popular these days, and sequences should be able to support them efficiently. At present, the best options are 1. Thread a counter through. This doesn't work well for weird things like lazy State. 2. Use zipWith first to add indices, then traverse. This adds a smaller, but still asymptotic, penalty to the same sorts of unusual functors, and also adds constant-factor overhead to strict ones that the counter threading wouldn't. I propose the following, modified mechanically from mapWithIndex. It should be about as efficient as possible in all cases. traverseWithIndex :: Applicative f => (Int -> a -> f b) -> Seq a -> f (Seq b) traverseWithIndex f' (Seq xs') = Seq <$> traverseWithIndexTree (\s (Elem a) -> Elem <$> f' s a) 0 xs' where traverseWithIndexTree :: (Applicative f, Sized a) => (Int -> a -> f b) -> Int -> FingerTree a -> f (FingerTree b) traverseWithIndexTree _ s Empty = s `seq` pure Empty traverseWithIndexTree f s (Single xs) = Single <$> f s xs traverseWithIndexTree f s (Deep n pr m sf) = sPspr `seq` sPsprm `seq` Deep n <$> traverseWithIndexDigit f s pr <*> traverseWithIndexTree (traverseWithIndexNode f) sPspr m <*> traverseWithIndexDigit f sPsprm sf where sPspr = s + size pr sPsprm = s + n - size sf traverseWithIndexDigit :: (Applicative f, Sized a) => (Int -> a -> f b) -> Int -> Digit a -> f (Digit b) traverseWithIndexDigit f s (One a) = One <$> f s a traverseWithIndexDigit f s (Two a b) = sPsa `seq` Two <$> f s a <*> f sPsa b where sPsa = s + size a traverseWithIndexDigit f s (Three a b c) = sPsa `seq` sPsab `seq` Three <$> f s a <*> f sPsa b <*> f sPsab c where sPsa = s + size a sPsab = sPsa + size b traverseWithIndexDigit f s (Four a b c d) = sPsa `seq` sPsab `seq` sPsabc `seq` Four <$> f s a <*> f sPsa b <*> f sPsab c <*> f sPsabc d where sPsa = s + size a sPsab = sPsa + size b sPsabc = sPsab + size c traverseWithIndexNode :: (Applicative f, Sized a) => (Int -> a -> f b) -> Int -> Node a -> f (Node b) traverseWithIndexNode f s (Node2 ns a b) = sPsa `seq` Node2 ns <$> f s a <*> f sPsa b where sPsa = s + size a traverseWithIndexNode f s (Node3 ns a b c) = sPsa `seq` sPsab `seq` Node3 ns <$> f s a <*> f sPsa b <*> f sPsab c where sPsa = s + size a sPsab = sPsa + size b From alois.cochard at gmail.com Tue Jan 19 17:01:03 2016 From: alois.cochard at gmail.com (Alois Cochard) Date: Tue, 19 Jan 2016 18:01:03 +0100 Subject: Add traverseWithIndex to Data.Sequence In-Reply-To: References: Message-ID: +1 for adding `traverseWithIndex`, I did look for that one more than once :) I don't have strong opinions for the other variations of the functions. On 19 January 2016 at 17:55, David Feuer wrote: > Indexed traversals seem to be pretty popular these days, and sequences > should be able to support them efficiently. At present, the best > options are > > 1. Thread a counter through. This doesn't work well for weird things > like lazy State. > > 2. Use zipWith first to add indices, then traverse. This adds a > smaller, but still asymptotic, penalty to the same sorts of unusual > functors, and also adds constant-factor overhead to strict ones that > the counter threading wouldn't. > > I propose the following, modified mechanically from mapWithIndex. It > should be about as efficient as possible in all cases. > > traverseWithIndex :: Applicative f => (Int -> a -> f b) -> Seq a -> f (Seq > b) > traverseWithIndex f' (Seq xs') = Seq <$> traverseWithIndexTree (\s > (Elem a) -> Elem <$> f' s a) 0 xs' > where > traverseWithIndexTree :: (Applicative f, Sized a) => (Int -> a -> f > b) -> Int -> FingerTree a -> f (FingerTree b) > traverseWithIndexTree _ s Empty = s `seq` pure Empty > traverseWithIndexTree f s (Single xs) = Single <$> f s xs > traverseWithIndexTree f s (Deep n pr m sf) = sPspr `seq` sPsprm `seq` > Deep n <$> > traverseWithIndexDigit f s pr <*> > traverseWithIndexTree (traverseWithIndexNode f) sPspr m <*> > traverseWithIndexDigit f sPsprm sf > where > sPspr = s + size pr > sPsprm = s + n - size sf > > traverseWithIndexDigit :: (Applicative f, Sized a) => (Int -> a -> f > b) -> Int -> Digit a -> f (Digit b) > traverseWithIndexDigit f s (One a) = One <$> f s a > traverseWithIndexDigit f s (Two a b) = sPsa `seq` Two <$> f s a <*> f > sPsa b > where > sPsa = s + size a > traverseWithIndexDigit f s (Three a b c) = sPsa `seq` sPsab `seq` > Three <$> f s a <*> f sPsa b <*> f > sPsab c > where > sPsa = s + size a > sPsab = sPsa + size b > traverseWithIndexDigit f s (Four a b c d) = sPsa `seq` sPsab `seq` > sPsabc `seq` > Four <$> f s a <*> f sPsa b <*> f sPsab c > <*> f sPsabc d > where > sPsa = s + size a > sPsab = sPsa + size b > sPsabc = sPsab + size c > > traverseWithIndexNode :: (Applicative f, Sized a) => (Int -> a -> f > b) -> Int -> Node a -> f (Node b) > traverseWithIndexNode f s (Node2 ns a b) = sPsa `seq` Node2 ns <$> f > s a <*> f sPsa b > where > sPsa = s + size a > traverseWithIndexNode f s (Node3 ns a b c) = sPsa `seq` sPsab `seq` > Node3 ns <$> f s a <*> f sPsa b > <*> f sPsab c > where > sPsa = s + size a > sPsab = sPsa + size b > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.mvd at gmail.com Tue Jan 19 18:38:37 2016 From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=) Date: Tue, 19 Jan 2016 18:38:37 +0000 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> Message-ID: +1 for distinguishing <= and implies. Ordering should not be tied to logical meaning. po 18. 1. 2016 v 19:38 odes?latel Henning Thielemann < lemming at henning-thielemann.de> napsal: > > On Mon, 18 Jan 2016, Brent Yorgey wrote: > > > I disagree. The equivalence between `implies` and (<=) depends on the > > ordering chosen for Bool, which is completely arbitrary, and is not > > something people thinking about logic should be expected to know or > > learn. For example, the Coq standard library happens to choose the > > other order, with True < False. > > I can confirm that the order is arbitrary. I used a Modula II > implementation where True was represented as -1, because that is the bit > pattern where all bits are > set._______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Tue Jan 19 20:32:51 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Tue, 19 Jan 2016 15:32:51 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> Message-ID: <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> > El 19 ene 2016, a las 10:24, Alois Cochard escribi?: > > +1 > > Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers). > Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision? Tom > >> On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote: >> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: >> > For some reason I really can't imagine, it seems the only tuple type >> > with a Functor instance is (,) a. I was astonished to find that >> > >> > fmap (+1) (1,2,3) >> > >> > doesn't work. Since this is *useful*, and there is *only one way to do >> > it*, I propose we add the following: >> > >> > instance Functor ((,,) a b) where >> > fmap f (a,b,c) = (a,b,f c) >> > instance Functor ((,,,) a b c) where >> > fmap f (a,b,c,d) = (a,b,c,f d) >> > etc. >> >> As stated elsewhere in this thread already, there is the issue about >> consistency. Here's a relevant section from the Haskell 2010 report[1]: >> >> > 6.1.4 Tuples >> > >> > ... >> > >> > However, every Haskell implementation must support tuples up to size >> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. >> >> IMO, we either have no `Functor` instances for tuples at all, or we have >> them for all tuples up to size 15. The current situations of having them >> defined only for 2-tuples is inconsistent. >> >> >> Cheers, >> hvr >> >> [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > ?\ois > http://twitter.com/aloiscochard > http://github.com/aloiscochard > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Tue Jan 19 20:54:38 2016 From: alois.cochard at gmail.com (Alois Cochard) Date: Tue, 19 Jan 2016 21:54:38 +0100 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> Message-ID: I don't have any use case like that. I'm in favor of this proposal for consistency sake. That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity. On 19 January 2016 at 21:32, wrote: > El 19 ene 2016, a las 10:24, Alois Cochard > escribi?: > > +1 > > Agree for consistency, I can also see those instances as being useful in > some specific context, even if I agree with Andreas that in general they > should be discouraged (especially for newcomers). > > > Can you give us an example where using e.g. the Functor instance for a > 5-tuple would be the correct/best design decision? > > Tom > > > > On 19 January 2016 at 09:20, Herbert Valerio Riedel > wrote: > >> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: >> > For some reason I really can't imagine, it seems the only tuple type >> > with a Functor instance is (,) a. I was astonished to find that >> > >> > fmap (+1) (1,2,3) >> > >> > doesn't work. Since this is *useful*, and there is *only one way to do >> > it*, I propose we add the following: >> > >> > instance Functor ((,,) a b) where >> > fmap f (a,b,c) = (a,b,f c) >> > instance Functor ((,,,) a b c) where >> > fmap f (a,b,c,d) = (a,b,c,f d) >> > etc. >> >> As stated elsewhere in this thread already, there is the issue about >> consistency. Here's a relevant section from the Haskell 2010 report[1]: >> >> > 6.1.4 Tuples >> > >> > ... >> > >> > However, every Haskell implementation must support tuples up to size >> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. >> >> IMO, we either have no `Functor` instances for tuples at all, or we have >> them for all tuples up to size 15. The current situations of having them >> defined only for 2-tuples is inconsistent. >> >> >> Cheers, >> hvr >> >> [1]: >> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > -- > *?\ois* > http://twitter.com/aloiscochard > http://github.com/aloiscochard > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Tue Jan 19 21:04:39 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Tue, 19 Jan 2016 16:04:39 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> Message-ID: <602FBE39-EF3C-486D-9EB1-FF542BAFB865@gmail.com> If the only uses we can imagine for these instances are - Cases where it's not a great design decision - Cases where it's used accidentally and results in a silent runtime failure instead of a compile-time error then I'm a strong -1 Tom > El 19 ene 2016, a las 15:54, Alois Cochard escribi?: > > I don't have any use case like that. I'm in favor of this proposal for consistency sake. > > That last part of my comment about usefulness/discouraging usage was about using Functor instance on tuple in general, no matter the arity. > >> On 19 January 2016 at 21:32, wrote: >>> El 19 ene 2016, a las 10:24, Alois Cochard escribi?: >>> >>> +1 >>> >>> Agree for consistency, I can also see those instances as being useful in some specific context, even if I agree with Andreas that in general they should be discouraged (especially for newcomers). >>> >> >> Can you give us an example where using e.g. the Functor instance for a 5-tuple would be the correct/best design decision? >> >> Tom >> >> >>> >>>> On 19 January 2016 at 09:20, Herbert Valerio Riedel wrote: >>>> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: >>>> > For some reason I really can't imagine, it seems the only tuple type >>>> > with a Functor instance is (,) a. I was astonished to find that >>>> > >>>> > fmap (+1) (1,2,3) >>>> > >>>> > doesn't work. Since this is *useful*, and there is *only one way to do >>>> > it*, I propose we add the following: >>>> > >>>> > instance Functor ((,,) a b) where >>>> > fmap f (a,b,c) = (a,b,f c) >>>> > instance Functor ((,,,) a b c) where >>>> > fmap f (a,b,c,d) = (a,b,c,f d) >>>> > etc. >>>> >>>> As stated elsewhere in this thread already, there is the issue about >>>> consistency. Here's a relevant section from the Haskell 2010 report[1]: >>>> >>>> > 6.1.4 Tuples >>>> > >>>> > ... >>>> > >>>> > However, every Haskell implementation must support tuples up to size >>>> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. >>>> >>>> IMO, we either have no `Functor` instances for tuples at all, or we have >>>> them for all tuples up to size 15. The current situations of having them >>>> defined only for 2-tuples is inconsistent. >>>> >>>> >>>> Cheers, >>>> hvr >>>> >>>> [1]: https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> >>> -- >>> ?\ois >>> http://twitter.com/aloiscochard >>> http://github.com/aloiscochard >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > ?\ois > http://twitter.com/aloiscochard > http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Jan 19 21:20:05 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 19 Jan 2016 16:20:05 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <602FBE39-EF3C-486D-9EB1-FF542BAFB865@gmail.com> References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <602FBE39-EF3C-486D-9EB1-FF542BAFB865@gmail.com> Message-ID: The problem, I think, is that 1. Many of us thing the instance for pairs is useful. Some of us think the instance for triples is occasionally useful. Most of us doubt the instances for large tuples are often useful (but I'm not quite convinced). 2. Most of us value consistency very highly. Even if we think the instance for pairs is great and the instance for septuples is silly, we want to have the same answer for all tuple sizes. Thus we have the usual "The axiom of choice is obviously true, the well-ordering principle is obviously false, and who can say about Zorn's lemma." Why I'm not quite convinced about large tuples being entirely silly: people do weird things with Template Haskell. When they do so, they want to be able to use functions as uniformly as possible. A function (fmap) that always hits the last component of a tuple, even if it has 15 components, may be just what they need. On Tue, Jan 19, 2016 at 4:04 PM, wrote: > If the only uses we can imagine for these instances are > - Cases where it's not a great design decision > - Cases where it's used accidentally and results in a silent runtime > failure instead of a compile-time error > > then I'm a strong -1 > > Tom > > El 19 ene 2016, a las 15:54, Alois Cochard > escribi?: > > I don't have any use case like that. I'm in favor of this proposal for > consistency sake. > > That last part of my comment about usefulness/discouraging usage was about > using Functor instance on tuple in general, no matter the arity. > > On 19 January 2016 at 21:32, wrote: >> >> El 19 ene 2016, a las 10:24, Alois Cochard >> escribi?: >> >> +1 >> >> Agree for consistency, I can also see those instances as being useful in >> some specific context, even if I agree with Andreas that in general they >> should be discouraged (especially for newcomers). >> >> >> Can you give us an example where using e.g. the Functor instance for a >> 5-tuple would be the correct/best design decision? >> >> Tom >> >> >> >> On 19 January 2016 at 09:20, Herbert Valerio Riedel >> wrote: >>> >>> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: >>> > For some reason I really can't imagine, it seems the only tuple type >>> > with a Functor instance is (,) a. I was astonished to find that >>> > >>> > fmap (+1) (1,2,3) >>> > >>> > doesn't work. Since this is *useful*, and there is *only one way to do >>> > it*, I propose we add the following: >>> > >>> > instance Functor ((,,) a b) where >>> > fmap f (a,b,c) = (a,b,f c) >>> > instance Functor ((,,,) a b c) where >>> > fmap f (a,b,c,d) = (a,b,c,f d) >>> > etc. >>> >>> As stated elsewhere in this thread already, there is the issue about >>> consistency. Here's a relevant section from the Haskell 2010 report[1]: >>> >>> > 6.1.4 Tuples >>> > >>> > ... >>> > >>> > However, every Haskell implementation must support tuples up to size >>> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. >>> >>> IMO, we either have no `Functor` instances for tuples at all, or we have >>> them for all tuples up to size 15. The current situations of having them >>> defined only for 2-tuples is inconsistent. >>> >>> >>> Cheers, >>> hvr >>> >>> [1]: >>> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> >> -- >> ?\ois >> http://twitter.com/aloiscochard >> http://github.com/aloiscochard >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > -- > ?\ois > http://twitter.com/aloiscochard > http://github.com/aloiscochard > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From cma at bitemyapp.com Tue Jan 19 21:22:27 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 19 Jan 2016 15:22:27 -0600 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <602FBE39-EF3C-486D-9EB1-FF542BAFB865@gmail.com> Message-ID: >Why I'm not quite convinced about large tuples being entirely silly: They happen to be a useful dumb type for things like rows you parse from a csv file or similar as well. Pretty sure the various *-simple database clients use this as well. They are, admittedly, sort of a paradigm case for why `lens` is often more useful than Functors, but Functor isn't going anywhere and there's only one valid instance for these types so they might as well live with the types or the class. On Tue, Jan 19, 2016 at 3:20 PM, David Feuer wrote: > The problem, I think, is that > > 1. Many of us thing the instance for pairs is useful. Some of us think > the instance for triples is occasionally useful. Most of us doubt the > instances for large tuples are often useful (but I'm not quite > convinced). > 2. Most of us value consistency very highly. Even if we think the > instance for pairs is great and the instance for septuples is silly, > we want to have the same answer for all tuple sizes. > > Thus we have the usual "The axiom of choice is obviously true, the > well-ordering principle is obviously false, and who can say about > Zorn's lemma." > > Why I'm not quite convinced about large tuples being entirely silly: > people do weird things with Template Haskell. When they do so, they > want to be able to use functions as uniformly as possible. A function > (fmap) that always hits the last component of a tuple, even if it has > 15 components, may be just what they need. > > On Tue, Jan 19, 2016 at 4:04 PM, wrote: > > If the only uses we can imagine for these instances are > > - Cases where it's not a great design decision > > - Cases where it's used accidentally and results in a silent runtime > > failure instead of a compile-time error > > > > then I'm a strong -1 > > > > Tom > > > > El 19 ene 2016, a las 15:54, Alois Cochard > > escribi?: > > > > I don't have any use case like that. I'm in favor of this proposal for > > consistency sake. > > > > That last part of my comment about usefulness/discouraging usage was > about > > using Functor instance on tuple in general, no matter the arity. > > > > On 19 January 2016 at 21:32, wrote: > >> > >> El 19 ene 2016, a las 10:24, Alois Cochard > >> escribi?: > >> > >> +1 > >> > >> Agree for consistency, I can also see those instances as being useful in > >> some specific context, even if I agree with Andreas that in general they > >> should be discouraged (especially for newcomers). > >> > >> > >> Can you give us an example where using e.g. the Functor instance for a > >> 5-tuple would be the correct/best design decision? > >> > >> Tom > >> > >> > >> > >> On 19 January 2016 at 09:20, Herbert Valerio Riedel > > >> wrote: > >>> > >>> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: > >>> > For some reason I really can't imagine, it seems the only tuple type > >>> > with a Functor instance is (,) a. I was astonished to find that > >>> > > >>> > fmap (+1) (1,2,3) > >>> > > >>> > doesn't work. Since this is *useful*, and there is *only one way to > do > >>> > it*, I propose we add the following: > >>> > > >>> > instance Functor ((,,) a b) where > >>> > fmap f (a,b,c) = (a,b,f c) > >>> > instance Functor ((,,,) a b c) where > >>> > fmap f (a,b,c,d) = (a,b,c,f d) > >>> > etc. > >>> > >>> As stated elsewhere in this thread already, there is the issue about > >>> consistency. Here's a relevant section from the Haskell 2010 report[1]: > >>> > >>> > 6.1.4 Tuples > >>> > > >>> > ... > >>> > > >>> > However, every Haskell implementation must support tuples up to size > >>> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. > >>> > >>> IMO, we either have no `Functor` instances for tuples at all, or we > have > >>> them for all tuples up to size 15. The current situations of having > them > >>> defined only for 2-tuples is inconsistent. > >>> > >>> > >>> Cheers, > >>> hvr > >>> > >>> [1]: > >>> > https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > >> > >> > >> > >> -- > >> ?\ois > >> http://twitter.com/aloiscochard > >> http://github.com/aloiscochard > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > > > > > -- > > ?\ois > > http://twitter.com/aloiscochard > > http://github.com/aloiscochard > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Jan 19 21:35:41 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 19 Jan 2016 21:35:41 +0000 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <602FBE39-EF3C-486D-9EB1-FF542BAFB865@gmail.com> References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <602FBE39-EF3C-486D-9EB1-FF542BAFB865@gmail.com> Message-ID: To directly answer the initial proposal, there seems to be little harm in functor instances for n-tuples. Functor instances are usually ok as one must always provide two arguments to fmap which agree with each other. There is little chance of using the wrong instance by accident. However, I am strongly against adding foldable and traversable instances for n-tuples. I thank Ryan for articulating why he finds them useful but due to the pervasive use of tuples to return multiple values from functions I find even the 2-tuple instance distasteful . It is very easy to introduce bugs when refactoring with the existence of these instances. If altering a function which returns a useful foldable such as lists to return a pair then if you ever call length on the returned value then you have introduced a difficult to track down bug. Unlike calls to fmap, there is no sanity check to make sure you are using the right instance. If there are other cases where such instances are useful then I would reconsider my position but I find the arguments for (a canonical instance and for consistency) unconvincing. It should not be the case that we propagate bad behaviour for the sake of consistency. I even think Ryan's use case would be better served by a separate datatype for that purpose. On 19 Jan 2016 21:04, wrote: > If the only uses we can imagine for these instances are > - Cases where it's not a great design decision > - Cases where it's used accidentally and results in a silent runtime > failure instead of a compile-time error > > then I'm a strong -1 > > Tom > > El 19 ene 2016, a las 15:54, Alois Cochard > escribi?: > > I don't have any use case like that. I'm in favor of this proposal for > consistency sake. > > That last part of my comment about usefulness/discouraging usage was about > using Functor instance on tuple in general, no matter the arity. > > On 19 January 2016 at 21:32, wrote: > >> El 19 ene 2016, a las 10:24, Alois Cochard >> escribi?: >> >> +1 >> >> Agree for consistency, I can also see those instances as being useful in >> some specific context, even if I agree with Andreas that in general they >> should be discouraged (especially for newcomers). >> >> >> Can you give us an example where using e.g. the Functor instance for a >> 5-tuple would be the correct/best design decision? >> >> Tom >> >> >> >> On 19 January 2016 at 09:20, Herbert Valerio Riedel >> wrote: >> >>> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: >>> > For some reason I really can't imagine, it seems the only tuple type >>> > with a Functor instance is (,) a. I was astonished to find that >>> > >>> > fmap (+1) (1,2,3) >>> > >>> > doesn't work. Since this is *useful*, and there is *only one way to do >>> > it*, I propose we add the following: >>> > >>> > instance Functor ((,,) a b) where >>> > fmap f (a,b,c) = (a,b,f c) >>> > instance Functor ((,,,) a b c) where >>> > fmap f (a,b,c,d) = (a,b,c,f d) >>> > etc. >>> >>> As stated elsewhere in this thread already, there is the issue about >>> consistency. Here's a relevant section from the Haskell 2010 report[1]: >>> >>> > 6.1.4 Tuples >>> > >>> > ... >>> > >>> > However, every Haskell implementation must support tuples up to size >>> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. >>> >>> IMO, we either have no `Functor` instances for tuples at all, or we have >>> them for all tuples up to size 15. The current situations of having them >>> defined only for 2-tuples is inconsistent. >>> >>> >>> Cheers, >>> hvr >>> >>> [1]: >>> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> >> >> -- >> *?\ois* >> http://twitter.com/aloiscochard >> http://github.com/aloiscochard >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > > -- > *?\ois* > http://twitter.com/aloiscochard > http://github.com/aloiscochard > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Tue Jan 19 21:50:37 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Tue, 19 Jan 2016 16:50:37 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <602FBE39-EF3C-486D-9EB1-FF542BAFB865@gmail.com> Message-ID: <1E9BBAD7-274A-442F-983D-949DD2409B5B@gmail.com> > El 19 ene 2016, a las 16:22, Christopher Allen escribi?: > > >Why I'm not quite convinced about large tuples being entirely silly: > > They happen to be a useful dumb type for things like rows you parse from a csv file or similar as well. Pretty sure the various *-simple database clients use this as well. > In these cases large tuples are useful, but a Functor instance that operates on the last element? > They are, admittedly, sort of a paradigm case for why `lens` is often more useful than Functors, but Functor isn't going anywhere and there's only one valid instance for these types so they might as well live with the types or the class. > My disagreement is only in "might as well": there is a downside to these, so I'd like there to be an upside (that's worth it!). Tom >> On Tue, Jan 19, 2016 at 3:20 PM, David Feuer wrote: >> The problem, I think, is that >> >> 1. Many of us thing the instance for pairs is useful. Some of us think >> the instance for triples is occasionally useful. Most of us doubt the >> instances for large tuples are often useful (but I'm not quite >> convinced). >> 2. Most of us value consistency very highly. Even if we think the >> instance for pairs is great and the instance for septuples is silly, >> we want to have the same answer for all tuple sizes. >> >> Thus we have the usual "The axiom of choice is obviously true, the >> well-ordering principle is obviously false, and who can say about >> Zorn's lemma." >> >> Why I'm not quite convinced about large tuples being entirely silly: >> people do weird things with Template Haskell. When they do so, they >> want to be able to use functions as uniformly as possible. A function >> (fmap) that always hits the last component of a tuple, even if it has >> 15 components, may be just what they need. >> >> On Tue, Jan 19, 2016 at 4:04 PM, wrote: >> > If the only uses we can imagine for these instances are >> > - Cases where it's not a great design decision >> > - Cases where it's used accidentally and results in a silent runtime >> > failure instead of a compile-time error >> > >> > then I'm a strong -1 >> > >> > Tom >> > >> > El 19 ene 2016, a las 15:54, Alois Cochard >> > escribi?: >> > >> > I don't have any use case like that. I'm in favor of this proposal for >> > consistency sake. >> > >> > That last part of my comment about usefulness/discouraging usage was about >> > using Functor instance on tuple in general, no matter the arity. >> > >> > On 19 January 2016 at 21:32, wrote: >> >> >> >> El 19 ene 2016, a las 10:24, Alois Cochard >> >> escribi?: >> >> >> >> +1 >> >> >> >> Agree for consistency, I can also see those instances as being useful in >> >> some specific context, even if I agree with Andreas that in general they >> >> should be discouraged (especially for newcomers). >> >> >> >> >> >> Can you give us an example where using e.g. the Functor instance for a >> >> 5-tuple would be the correct/best design decision? >> >> >> >> Tom >> >> >> >> >> >> >> >> On 19 January 2016 at 09:20, Herbert Valerio Riedel >> >> wrote: >> >>> >> >>> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: >> >>> > For some reason I really can't imagine, it seems the only tuple type >> >>> > with a Functor instance is (,) a. I was astonished to find that >> >>> > >> >>> > fmap (+1) (1,2,3) >> >>> > >> >>> > doesn't work. Since this is *useful*, and there is *only one way to do >> >>> > it*, I propose we add the following: >> >>> > >> >>> > instance Functor ((,,) a b) where >> >>> > fmap f (a,b,c) = (a,b,f c) >> >>> > instance Functor ((,,,) a b c) where >> >>> > fmap f (a,b,c,d) = (a,b,c,f d) >> >>> > etc. >> >>> >> >>> As stated elsewhere in this thread already, there is the issue about >> >>> consistency. Here's a relevant section from the Haskell 2010 report[1]: >> >>> >> >>> > 6.1.4 Tuples >> >>> > >> >>> > ... >> >>> > >> >>> > However, every Haskell implementation must support tuples up to size >> >>> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. >> >>> >> >>> IMO, we either have no `Functor` instances for tuples at all, or we have >> >>> them for all tuples up to size 15. The current situations of having them >> >>> defined only for 2-tuples is inconsistent. >> >>> >> >>> >> >>> Cheers, >> >>> hvr >> >>> >> >>> [1]: >> >>> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 >> >>> _______________________________________________ >> >>> Libraries mailing list >> >>> Libraries at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> >> >> >> >> >> >> -- >> >> ?\ois >> >> http://twitter.com/aloiscochard >> >> http://github.com/aloiscochard >> >> >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> > >> > >> > >> > -- >> > ?\ois >> > http://twitter.com/aloiscochard >> > http://github.com/aloiscochard >> > >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > Chris Allen > Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Jan 19 23:12:58 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 19 Jan 2016 18:12:58 -0500 Subject: Add traverseWithIndex to Data.Sequence In-Reply-To: <20160119172400.GA1437@auryn.cz> References: <20160119172400.GA1437@auryn.cz> Message-ID: I just realized there *is* a way to implement traverseWithIndex reasonably efficiently with the current interface: traverseWithIndex f = sequenceA . mapWithIndex f I still think it's a good thing to add though. On Jan 19, 2016 12:24 PM, "Milan Straka" wrote: > Hi David and all, > > > -----Original message----- > > From: David Feuer > > Sent: 19 Jan 2016, 11:55 > > > > Indexed traversals seem to be pretty popular these days, and sequences > > should be able to support them efficiently. At present, the best > > options are > > > > 1. Thread a counter through. This doesn't work well for weird things > > like lazy State. > > > > 2. Use zipWith first to add indices, then traverse. This adds a > > smaller, but still asymptotic, penalty to the same sorts of unusual > > functors, and also adds constant-factor overhead to strict ones that > > the counter threading wouldn't. > > > > I propose the following, modified mechanically from mapWithIndex. It > > should be about as efficient as possible in all cases. > > +1 from me. > > BTW, we have traverseWithKey in Map and IntMap, and traverseWithIndex > seems a bit analogous for (indexable) Sequences, where an index can play > a role of a key. > > Cheers, > Milan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Jan 19 23:31:05 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 19 Jan 2016 18:31:05 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> Message-ID: Let's do a 3-tuple because it doesn't require any contortions to find a real usecase. type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t if you want to return two results from a lens, by picking f = (,,) result1 result2 you can pass it a function a -> (result1, result2, b) and you'll get a function s -> (result1, result2, t) which modifies the structure using the supplied function and gives back both results and the final answer. You could of course make up a completely one-off data type with local instances and a ton of boilerplate. You could play games with nesting tuples, and get worse operational behavior and have an extra bottom and indirection to concern yourself with. Or you could just use the only possible instance we can put on a 3-tuple for Functor. -Edward On Tue, Jan 19, 2016 at 3:32 PM, wrote: > El 19 ene 2016, a las 10:24, Alois Cochard > escribi?: > > +1 > > Agree for consistency, I can also see those instances as being useful in > some specific context, even if I agree with Andreas that in general they > should be discouraged (especially for newcomers). > > > Can you give us an example where using e.g. the Functor instance for a > 5-tuple would be the correct/best design decision? > > Tom > > > > On 19 January 2016 at 09:20, Herbert Valerio Riedel > wrote: > >> On 2016-01-18 at 21:10:07 +0100, David Feuer wrote: >> > For some reason I really can't imagine, it seems the only tuple type >> > with a Functor instance is (,) a. I was astonished to find that >> > >> > fmap (+1) (1,2,3) >> > >> > doesn't work. Since this is *useful*, and there is *only one way to do >> > it*, I propose we add the following: >> > >> > instance Functor ((,,) a b) where >> > fmap f (a,b,c) = (a,b,f c) >> > instance Functor ((,,,) a b c) where >> > fmap f (a,b,c,d) = (a,b,c,f d) >> > etc. >> >> As stated elsewhere in this thread already, there is the issue about >> consistency. Here's a relevant section from the Haskell 2010 report[1]: >> >> > 6.1.4 Tuples >> > >> > ... >> > >> > However, every Haskell implementation must support tuples up to size >> > 15, together with the instances for Eq, Ord, Bounded, Read, and Show. >> >> IMO, we either have no `Functor` instances for tuples at all, or we have >> them for all tuples up to size 15. The current situations of having them >> defined only for 2-tuples is inconsistent. >> >> >> Cheers, >> hvr >> >> [1]: >> https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1210006.1.4 >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > -- > *?\ois* > http://twitter.com/aloiscochard > http://github.com/aloiscochard > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Jan 20 00:17:34 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 19 Jan 2016 19:17:34 -0500 Subject: Add traverseWithIndex to Data.Sequence In-Reply-To: References: Message-ID: +1 from me to add something along this line. Right now I hack around it's lack in lens using a rather inefficient codepath. -Edward On Tue, Jan 19, 2016 at 11:55 AM, David Feuer wrote: > Indexed traversals seem to be pretty popular these days, and sequences > should be able to support them efficiently. At present, the best > options are > > 1. Thread a counter through. This doesn't work well for weird things > like lazy State. > > 2. Use zipWith first to add indices, then traverse. This adds a > smaller, but still asymptotic, penalty to the same sorts of unusual > functors, and also adds constant-factor overhead to strict ones that > the counter threading wouldn't. > > I propose the following, modified mechanically from mapWithIndex. It > should be about as efficient as possible in all cases. > > traverseWithIndex :: Applicative f => (Int -> a -> f b) -> Seq a -> f (Seq > b) > traverseWithIndex f' (Seq xs') = Seq <$> traverseWithIndexTree (\s > (Elem a) -> Elem <$> f' s a) 0 xs' > where > traverseWithIndexTree :: (Applicative f, Sized a) => (Int -> a -> f > b) -> Int -> FingerTree a -> f (FingerTree b) > traverseWithIndexTree _ s Empty = s `seq` pure Empty > traverseWithIndexTree f s (Single xs) = Single <$> f s xs > traverseWithIndexTree f s (Deep n pr m sf) = sPspr `seq` sPsprm `seq` > Deep n <$> > traverseWithIndexDigit f s pr <*> > traverseWithIndexTree (traverseWithIndexNode f) sPspr m <*> > traverseWithIndexDigit f sPsprm sf > where > sPspr = s + size pr > sPsprm = s + n - size sf > > traverseWithIndexDigit :: (Applicative f, Sized a) => (Int -> a -> f > b) -> Int -> Digit a -> f (Digit b) > traverseWithIndexDigit f s (One a) = One <$> f s a > traverseWithIndexDigit f s (Two a b) = sPsa `seq` Two <$> f s a <*> f > sPsa b > where > sPsa = s + size a > traverseWithIndexDigit f s (Three a b c) = sPsa `seq` sPsab `seq` > Three <$> f s a <*> f sPsa b <*> f > sPsab c > where > sPsa = s + size a > sPsab = sPsa + size b > traverseWithIndexDigit f s (Four a b c d) = sPsa `seq` sPsab `seq` > sPsabc `seq` > Four <$> f s a <*> f sPsa b <*> f sPsab c > <*> f sPsabc d > where > sPsa = s + size a > sPsab = sPsa + size b > sPsabc = sPsab + size c > > traverseWithIndexNode :: (Applicative f, Sized a) => (Int -> a -> f > b) -> Int -> Node a -> f (Node b) > traverseWithIndexNode f s (Node2 ns a b) = sPsa `seq` Node2 ns <$> f > s a <*> f sPsa b > where > sPsa = s + size a > traverseWithIndexNode f s (Node3 ns a b c) = sPsa `seq` sPsab `seq` > Node3 ns <$> f s a <*> f sPsa b > <*> f sPsab c > where > sPsa = s + size a > sPsab = sPsa + size b > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Wed Jan 20 07:22:14 2016 From: johnw at newartisans.com (John Wiegley) Date: Tue, 19 Jan 2016 23:22:14 -0800 Subject: Add traverseWithIndex to Data.Sequence In-Reply-To: (David Feuer's message of "Tue, 19 Jan 2016 18:12:58 -0500") References: <20160119172400.GA1437@auryn.cz> Message-ID: >>>>> David Feuer writes: > I just realized there *is* a way to implement traverseWithIndex reasonably > efficiently with the current interface: > traverseWithIndex f = sequenceA . mapWithIndex f > I still think it's a good thing to add though. +1 -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From alexander at plaimi.net Wed Jan 20 12:48:06 2016 From: alexander at plaimi.net (Alexander Berntsen) Date: Wed, 20 Jan 2016 13:48:06 +0100 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> Message-ID: <569F8206.4020203@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 19/01/16 21:54, Alois Cochard wrote: > I'm in favor of this proposal for consistency sake. As am I. Inconsistency seems like laziness at best, and poorly thought through at worst. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq 2FQ1Dqbh8LiC9dZXNuSD =Cep6 -----END PGP SIGNATURE----- From ollie at ocharles.org.uk Wed Jan 20 12:50:46 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 20 Jan 2016 12:50:46 +0000 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: <569F8206.4020203@plaimi.net> References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <569F8206.4020203@plaimi.net> Message-ID: I'm not sure I even want to propose this, but if you're going to make it consistent for all tuples, should you also make Bifunctor consistent for all tuples? On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 19/01/16 21:54, Alois Cochard wrote: > > I'm in favor of this proposal for consistency sake. > As am I. Inconsistency seems like laziness at best, and poorly thought > through at worst. > > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA > pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur > GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm > tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM > feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV > 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x > xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b > yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp > H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l > 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo > lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq > 2FQ1Dqbh8LiC9dZXNuSD > =Cep6 > -----END PGP SIGNATURE----- > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Jan 20 13:07:01 2016 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 20 Jan 2016 08:07:01 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <569F8206.4020203@plaimi.net> Message-ID: On Wed, Jan 20, 2016 at 7:50 AM, Oliver Charles wrote: > I'm not sure I even want to propose this, but if you're going to make it > consistent for all tuples, should you also make Bifunctor consistent for > all tuples? > The Bifunctor instances are already defined out to 7-tuples or so. -Edward > On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 19/01/16 21:54, Alois Cochard wrote: >> > I'm in favor of this proposal for consistency sake. >> As am I. Inconsistency seems like laziness at best, and poorly thought >> through at worst. >> >> - -- >> Alexander >> alexander at plaimi.net >> https://secure.plaimi.net/~alexander >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA >> pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur >> GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm >> tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM >> feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV >> 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x >> xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b >> yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp >> H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l >> 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo >> lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq >> 2FQ1Dqbh8LiC9dZXNuSD >> =Cep6 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From milan at strakovi.com Tue Jan 19 17:24:00 2016 From: milan at strakovi.com (Milan Straka) Date: Tue, 19 Jan 2016 18:24:00 +0100 Subject: Add traverseWithIndex to Data.Sequence In-Reply-To: References: Message-ID: <20160119172400.GA1437@auryn.cz> Hi David and all, > -----Original message----- > From: David Feuer > Sent: 19 Jan 2016, 11:55 > > Indexed traversals seem to be pretty popular these days, and sequences > should be able to support them efficiently. At present, the best > options are > > 1. Thread a counter through. This doesn't work well for weird things > like lazy State. > > 2. Use zipWith first to add indices, then traverse. This adds a > smaller, but still asymptotic, penalty to the same sorts of unusual > functors, and also adds constant-factor overhead to strict ones that > the counter threading wouldn't. > > I propose the following, modified mechanically from mapWithIndex. It > should be about as efficient as possible in all cases. +1 from me. BTW, we have traverseWithKey in Map and IntMap, and traverseWithIndex seems a bit analogous for (indexable) Sequences, where an index can play a role of a key. Cheers, Milan From ollie at ocharles.org.uk Wed Jan 20 13:49:52 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 20 Jan 2016 13:49:52 +0000 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <569F8206.4020203@plaimi.net> Message-ID: Right, and people here are talking about adding Functor for up to 15-tuples, unless I misread. On Wed, Jan 20, 2016 at 1:07 PM Edward Kmett wrote: > On Wed, Jan 20, 2016 at 7:50 AM, Oliver Charles > wrote: > >> I'm not sure I even want to propose this, but if you're going to make it >> consistent for all tuples, should you also make Bifunctor consistent for >> all tuples? >> > > The Bifunctor instances are already defined out to 7-tuples or so. > > -Edward > > >> On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA512 >>> >>> On 19/01/16 21:54, Alois Cochard wrote: >>> > I'm in favor of this proposal for consistency sake. >>> As am I. Inconsistency seems like laziness at best, and poorly thought >>> through at worst. >>> >>> - -- >>> Alexander >>> alexander at plaimi.net >>> https://secure.plaimi.net/~alexander >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2 >>> >>> iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA >>> pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur >>> GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm >>> tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM >>> feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV >>> 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x >>> xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b >>> yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp >>> H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l >>> 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo >>> lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq >>> 2FQ1Dqbh8LiC9dZXNuSD >>> =Cep6 >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Wed Jan 20 14:43:54 2016 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Wed, 20 Jan 2016 09:43:54 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <1453150748.323533.495630730.20735479@webmail.messagingengine.com> Message-ID: <569F9D2A.7080300@stilo.com> On 16-01-18 04:17 PM, amindfv at gmail.com wrote: > I share Henning's concerns. Can someone provide a realistic example > of where an instance for (,,) or (,,,) *is* desirable? I'm looking at some examples in production code here at work: > firstOfThree (a, b, c) = a > onFirstOfThree f = changeNode (\(a, b, c)-> (f a, b, c)) The triple that's being manipulated is local to a bigger function, and the order of its a, b, c parameters is arbitrary. If this code was written in presence of the proposed instances, the first parameter would likely become the last, and at least the latter function would be dropped: > onLastOfThree = fmap I'm not convinced there's any downside, so I'm +1 on the proposal. From ekmett at gmail.com Wed Jan 20 16:03:33 2016 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 20 Jan 2016 11:03:33 -0500 Subject: Proposal: Add conspicuously missing Functor instances for tuples In-Reply-To: References: <87oacic74l.fsf@gmail.com> <1DD1827D-F196-4F15-85C8-25AA368D4D4F@gmail.com> <569F8206.4020203@plaimi.net> Message-ID: Fair enough, I missed that statement and I have no particular preference on how high the ceiling gets raised beyond 4-5 if somebody else is willing to write the patch. ;) -Edward On Wed, Jan 20, 2016 at 8:49 AM, Oliver Charles wrote: > Right, and people here are talking about adding Functor for up to > 15-tuples, unless I misread. > > On Wed, Jan 20, 2016 at 1:07 PM Edward Kmett wrote: > >> On Wed, Jan 20, 2016 at 7:50 AM, Oliver Charles >> wrote: >> >>> I'm not sure I even want to propose this, but if you're going to make it >>> consistent for all tuples, should you also make Bifunctor consistent for >>> all tuples? >>> >> >> The Bifunctor instances are already defined out to 7-tuples or so. >> >> -Edward >> >> >>> On Wed, Jan 20, 2016 at 12:48 PM Alexander Berntsen < >>> alexander at plaimi.net> wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA512 >>>> >>>> On 19/01/16 21:54, Alois Cochard wrote: >>>> > I'm in favor of this proposal for consistency sake. >>>> As am I. Inconsistency seems like laziness at best, and poorly thought >>>> through at worst. >>>> >>>> - -- >>>> Alexander >>>> alexander at plaimi.net >>>> https://secure.plaimi.net/~alexander >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2 >>>> >>>> iQIcBAEBCgAGBQJWn4IFAAoJENQqWdRUGk8Bbs4P/RVit2hXVpWn6AaK+zgA8KOA >>>> pHyzK93KY+ASLbaWEzsMYwtoreYY1/Rd+xby1St35QGiJm6gEr+LME2LWfWITOur >>>> GlPrAWUps/TqipA49JioVKMMOwqub6mcVXisLZt8DGe84pZNarzZXUBh5FGblkGm >>>> tZg2tsNT9QEUjodAVi0yf1P+wHNaDz9XaX8/upKMYjkW4tZyeldMky+HBvwBJ8XM >>>> feQ3tOTK5dgHPM0ssmUIAVIlL1z0VUmJ6skSNBfQotkCnQRE3uHFagXsCPMGe7gV >>>> 9jvLJ1ZHLXFWdS3KtT2UMUzmdQPmygwWCc9jOWZsJr4ndoKBKYConmmYs+Vzvy2x >>>> xKqDrHVuKOcEgOOkTHSdXnsw6Wdjs0N9Vw5mc+zFeymf9NoWJeqgijKfInS+jR0b >>>> yNYYoVILFY22ISua89dRws0+Ky9gCWkKIbu/+uCteFlXoMv3j60LnmUuoZ3kY+bp >>>> H5+c4v3sEObjItbYsRLEo6KiACC1I1bhFJm16+XipAgY0N31R4R9Hr6sCo+yWa2l >>>> 9bNJn8KJ/p9N2JZMRUzo2KVwet9VpGq9PP90DDuwf+Nz3xYttWGIUFRgec7OzmHo >>>> lYfUWqAtbOP0XguprV2fbxb9Ye3JF0RdqlVoRJCtAlppEkqmu0w8NEt3Uye+ZTkq >>>> 2FQ1Dqbh8LiC9dZXNuSD >>>> =Cep6 >>>> -----END PGP SIGNATURE----- >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Thu Jan 21 19:28:53 2016 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 21 Jan 2016 17:28:53 -0200 Subject: Proposal: Data.Bool.implies In-Reply-To: <569C4B48.6060507@nh2.me> References: <569C4B48.6060507@nh2.me> Message-ID: <56A13175.8090502@gmail.com> +1 for either Data.Bool.implies or Data.Bool.(==>). +1 for right-associativity. Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From iavor.diatchki at gmail.com Fri Jan 22 17:24:48 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 22 Jan 2016 09:24:48 -0800 Subject: Proposal: Data.Bool.implies In-Reply-To: <56A13175.8090502@gmail.com> References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> Message-ID: Please don't change the ordering on Bool---it's been like that forever and it might lead to extremely subtle bugs that won't be caught by the compiler. I am ambivalent about adding an `implies` function as long as it is not automatically in scope. However, can anyone give some examples of using this in your code? All the ones I could think of would seem easier to follow when written with `if-then-else` or a guard. -Iavor On Thu, Jan 21, 2016 at 11:28 AM, Felipe Lessa wrote: > +1 for either Data.Bool.implies or Data.Bool.(==>). > > +1 for right-associativity. > > Cheers, > > -- > Felipe. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan at evanrutledgeborden.dreamhosters.com Fri Jan 22 17:59:38 2016 From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com) Date: Fri, 22 Jan 2016 12:59:38 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> Message-ID: +1 For not changing the Ord instance for Bool. It would be disastrous. As an aside, is the Order instance for Bool in the report? On Jan 22, 2016 12:24 PM, "Iavor Diatchki" wrote: > Please don't change the ordering on Bool---it's been like that forever and > it might lead to extremely subtle bugs that won't be caught by the compiler. > > I am ambivalent about adding an `implies` function as long as it is not > automatically in scope. However, can anyone give some examples of using > this in your code? All the ones I could think of would seem easier to > follow when written with `if-then-else` or a guard. > > -Iavor > > > > > On Thu, Jan 21, 2016 at 11:28 AM, Felipe Lessa > wrote: > >> +1 for either Data.Bool.implies or Data.Bool.(==>). >> >> +1 for right-associativity. >> >> Cheers, >> >> -- >> Felipe. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan at evanrutledgeborden.dreamhosters.com Fri Jan 22 18:11:23 2016 From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com) Date: Fri, 22 Jan 2016 13:11:23 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> Message-ID: Answering my own question, yes it is in the report. >From the report: > 6.1.1 Booleans > > data Bool = False | True deriving > (Read, Show, Eq, Ord, Enum, Bounded) > > *11.1 Derived instances of Eq and * > *Ord* > ...For example, for the Bool datatype, we have that (True > False) == True > . > On Fri, Jan 22, 2016 at 12:59 PM, evan at evan-borden.com < evan at evanrutledgeborden.dreamhosters.com> wrote: > +1 For not changing the Ord instance for Bool. It would be disastrous. As > an aside, is the Order instance for Bool in the report? > On Jan 22, 2016 12:24 PM, "Iavor Diatchki" > wrote: > >> Please don't change the ordering on Bool---it's been like that forever >> and it might lead to extremely subtle bugs that won't be caught by the >> compiler. >> >> I am ambivalent about adding an `implies` function as long as it is not >> automatically in scope. However, can anyone give some examples of using >> this in your code? All the ones I could think of would seem easier to >> follow when written with `if-then-else` or a guard. >> >> -Iavor >> >> >> >> >> On Thu, Jan 21, 2016 at 11:28 AM, Felipe Lessa >> wrote: >> >>> +1 for either Data.Bool.implies or Data.Bool.(==>). >>> >>> +1 for right-associativity. >>> >>> Cheers, >>> >>> -- >>> Felipe. >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Jan 22 20:13:57 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 22 Jan 2016 15:13:57 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> Message-ID: How exactly would making the Ord instance for Bool lazier be "disastrous"? On Fri, Jan 22, 2016 at 12:59 PM, evan at evan-borden.com wrote: > +1 For not changing the Ord instance for Bool. It would be disastrous. As an > aside, is the Order instance for Bool in the report? > > On Jan 22, 2016 12:24 PM, "Iavor Diatchki" wrote: >> >> Please don't change the ordering on Bool---it's been like that forever and >> it might lead to extremely subtle bugs that won't be caught by the compiler. >> >> I am ambivalent about adding an `implies` function as long as it is not >> automatically in scope. However, can anyone give some examples of using >> this in your code? All the ones I could think of would seem easier to >> follow when written with `if-then-else` or a guard. >> >> -Iavor >> >> >> >> >> On Thu, Jan 21, 2016 at 11:28 AM, Felipe Lessa >> wrote: >>> >>> +1 for either Data.Bool.implies or Data.Bool.(==>). >>> >>> +1 for right-associativity. >>> >>> Cheers, >>> >>> -- >>> Felipe. >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From lemming at henning-thielemann.de Fri Jan 22 20:18:36 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 22 Jan 2016 21:18:36 +0100 (CET) Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> Message-ID: On Fri, 22 Jan 2016, David Feuer wrote: > How exactly would making the Ord instance for Bool lazier be "disastrous"? I think he talked about making fromEnum True = 0 and fromEnum False = 1. From mail at nh2.me Fri Jan 22 23:48:38 2016 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Sat, 23 Jan 2016 00:48:38 +0100 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> Message-ID: <56A2BFD6.40705@nh2.me> On 22/01/16 18:24, Iavor Diatchki wrote: > I am ambivalent about adding an `implies` function as long as it is not > automatically in scope. However, can anyone give some examples of using > this in your code? All the ones I could think of would seem easier to > follow when written with `if-then-else` or a guard. I use it e.g. in assert (isProduction `implies` (iterations > 50)) $ ... other code ... From david.feuer at gmail.com Sun Jan 24 21:24:16 2016 From: david.feuer at gmail.com (David Feuer) Date: Sun, 24 Jan 2016 16:24:16 -0500 Subject: Type class for sanity Message-ID: Since type families can be stuck, it's sometimes useful to restrict things to sane types. At present, the most convenient way I can see to do this in general is with Typeable: type family Foo x where Foo 'True = Int class Typeable (Foo x) => Bar x where blah :: proxy x -> Foo x This will prevent anyone from producing the bogus instance instance Bar 'False where blah _ = undefined Unfortunately, the Typeable constraint carries runtime overhead. One possible way around this, I think, is with a class that does just sanity checking and nothing more: class Sane (a :: k) instance Sane Int instance Sane Char instance Sane 'False instance Sane 'True instance Sane '[] instance Sane '(:) instance Sane (->) instance Sane 'Just instance Sane 'Nothing instance (Sane f, Sane x) => Sane (f x) To really do its job properly, Sane would need to have instances for all sane types and no more. An example of an insane instance of Sane would be instance Sane (a :: MyKind) which would include stuck types of kind MyKind. Would it be useful to add such an automatic-only class to GHC? David From jeffbrown.the at gmail.com Mon Jan 25 06:01:28 2016 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sun, 24 Jan 2016 22:01:28 -0800 Subject: Type class for sanity In-Reply-To: References: Message-ID: "Stuck type" is proving difficult to Google. Do you recommend any references? On Sun, Jan 24, 2016 at 1:24 PM, David Feuer wrote: > Since type families can be stuck, it's sometimes useful to restrict > things to sane types. At present, the most convenient way I can see to > do this in general is with Typeable: > > type family Foo x where > Foo 'True = Int > > class Typeable (Foo x) => Bar x where > blah :: proxy x -> Foo x > > This will prevent anyone from producing the bogus instance > > instance Bar 'False where > blah _ = undefined > > Unfortunately, the Typeable constraint carries runtime overhead. One > possible way around this, I think, is with a class that does just > sanity checking and nothing more: > > class Sane (a :: k) > instance Sane Int > instance Sane Char > instance Sane 'False > instance Sane 'True > instance Sane '[] > instance Sane '(:) > instance Sane (->) > instance Sane 'Just > instance Sane 'Nothing > instance (Sane f, Sane x) => Sane (f x) > > To really do its job properly, Sane would need to have instances for > all sane types and no more. An example of an insane instance of Sane > would be > > instance Sane (a :: MyKind) > > which would include stuck types of kind MyKind. > > Would it be useful to add such an automatic-only class to GHC? > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Jeffrey Benjamin Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Jan 25 06:23:13 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jan 2016 01:23:13 -0500 Subject: Type class for sanity In-Reply-To: References: Message-ID: See https://typesandkinds.wordpress.com/2015/09/09/what-are-type-families/ for some discussion. A type family application is stuck if it can't reduce further and has not reached a proper type. Given the aforementioned type family Foo, the application Foo 'False is stuck. It's a type of kind *, and it's uninhabited (but not as nicely uninhabited as Void--it offers no ex falso). This actually turns out to be useful for some things. GHC offers type family Any :: k where {} which is, at least, 1. A safe intermediate target for unsafeCoerce 2. An utterly unsatisfiable constraint (see the definition of Bottom in the GitHub master of the reflection package) But sometimes you want to know something's *not* a stuck type family. See the issue I filed earlier today at https://github.com/kwf/ComonadSheet/issues/6 for an example--the code tries to make a certain instance impossible to produce, but the possibility of stuckness defeats it as its currently written. On Jan 25, 2016 1:01 AM, "Jeffrey Brown" wrote: > "Stuck type" is proving difficult to Google. Do you recommend any > references? > > On Sun, Jan 24, 2016 at 1:24 PM, David Feuer > wrote: > >> Since type families can be stuck, it's sometimes useful to restrict >> things to sane types. At present, the most convenient way I can see to >> do this in general is with Typeable: >> >> type family Foo x where >> Foo 'True = Int >> >> class Typeable (Foo x) => Bar x where >> blah :: proxy x -> Foo x >> >> This will prevent anyone from producing the bogus instance >> >> instance Bar 'False where >> blah _ = undefined >> >> Unfortunately, the Typeable constraint carries runtime overhead. One >> possible way around this, I think, is with a class that does just >> sanity checking and nothing more: >> >> class Sane (a :: k) >> instance Sane Int >> instance Sane Char >> instance Sane 'False >> instance Sane 'True >> instance Sane '[] >> instance Sane '(:) >> instance Sane (->) >> instance Sane 'Just >> instance Sane 'Nothing >> instance (Sane f, Sane x) => Sane (f x) >> >> To really do its job properly, Sane would need to have instances for >> all sane types and no more. An example of an insane instance of Sane >> would be >> >> instance Sane (a :: MyKind) >> >> which would include stuck types of kind MyKind. >> >> Would it be useful to add such an automatic-only class to GHC? >> >> David >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > -- > Jeffrey Benjamin Brown > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jan 25 12:34:18 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 25 Jan 2016 07:34:18 -0500 Subject: Type class for sanity In-Reply-To: References: Message-ID: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> +1 This would be very easy to implement, too. But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > Since type families can be stuck, it's sometimes useful to restrict > things to sane types. At present, the most convenient way I can see to > do this in general is with Typeable: > > type family Foo x where > Foo 'True = Int > > class Typeable (Foo x) => Bar x where > blah :: proxy x -> Foo x > > This will prevent anyone from producing the bogus instance > > instance Bar 'False where > blah _ = undefined > > Unfortunately, the Typeable constraint carries runtime overhead. One > possible way around this, I think, is with a class that does just > sanity checking and nothing more: > > class Sane (a :: k) > instance Sane Int > instance Sane Char > instance Sane 'False > instance Sane 'True > instance Sane '[] > instance Sane '(:) > instance Sane (->) > instance Sane 'Just > instance Sane 'Nothing > instance (Sane f, Sane x) => Sane (f x) > > To really do its job properly, Sane would need to have instances for > all sane types and no more. An example of an insane instance of Sane > would be > > instance Sane (a :: MyKind) > > which would include stuck types of kind MyKind. > > Would it be useful to add such an automatic-only class to GHC? > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From david.feuer at gmail.com Mon Jan 25 13:44:19 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jan 2016 08:44:19 -0500 Subject: Type class for sanity In-Reply-To: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> Message-ID: I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? On Jan 25, 2016 7:34 AM, "Richard Eisenberg" wrote: > +1 > > This would be very easy to implement, too. > > But I suggest a different name. Ground? Terminating? NormalForm? > Irreducible? ValueType? I don't love any of these, but I love Sane less. > > On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > > > Since type families can be stuck, it's sometimes useful to restrict > > things to sane types. At present, the most convenient way I can see to > > do this in general is with Typeable: > > > > type family Foo x where > > Foo 'True = Int > > > > class Typeable (Foo x) => Bar x where > > blah :: proxy x -> Foo x > > > > This will prevent anyone from producing the bogus instance > > > > instance Bar 'False where > > blah _ = undefined > > > > Unfortunately, the Typeable constraint carries runtime overhead. One > > possible way around this, I think, is with a class that does just > > sanity checking and nothing more: > > > > class Sane (a :: k) > > instance Sane Int > > instance Sane Char > > instance Sane 'False > > instance Sane 'True > > instance Sane '[] > > instance Sane '(:) > > instance Sane (->) > > instance Sane 'Just > > instance Sane 'Nothing > > instance (Sane f, Sane x) => Sane (f x) > > > > To really do its job properly, Sane would need to have instances for > > all sane types and no more. An example of an insane instance of Sane > > would be > > > > instance Sane (a :: MyKind) > > > > which would include stuck types of kind MyKind. > > > > Would it be useful to add such an automatic-only class to GHC? > > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jan 25 14:05:58 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 25 Jan 2016 09:05:58 -0500 Subject: Type class for sanity In-Reply-To: References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> Message-ID: <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for someone and going all the way to nf would be less efficient / impossible. Richard On Jan 25, 2016, at 8:44 AM, David Feuer wrote: > I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? > > On Jan 25, 2016 7:34 AM, "Richard Eisenberg" wrote: > +1 > > This would be very easy to implement, too. > > But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. > > On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > > > Since type families can be stuck, it's sometimes useful to restrict > > things to sane types. At present, the most convenient way I can see to > > do this in general is with Typeable: > > > > type family Foo x where > > Foo 'True = Int > > > > class Typeable (Foo x) => Bar x where > > blah :: proxy x -> Foo x > > > > This will prevent anyone from producing the bogus instance > > > > instance Bar 'False where > > blah _ = undefined > > > > Unfortunately, the Typeable constraint carries runtime overhead. One > > possible way around this, I think, is with a class that does just > > sanity checking and nothing more: > > > > class Sane (a :: k) > > instance Sane Int > > instance Sane Char > > instance Sane 'False > > instance Sane 'True > > instance Sane '[] > > instance Sane '(:) > > instance Sane (->) > > instance Sane 'Just > > instance Sane 'Nothing > > instance (Sane f, Sane x) => Sane (f x) > > > > To really do its job properly, Sane would need to have instances for > > all sane types and no more. An example of an insane instance of Sane > > would be > > > > instance Sane (a :: MyKind) > > > > which would include stuck types of kind MyKind. > > > > Would it be useful to add such an automatic-only class to GHC? > > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Jan 25 14:21:09 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 25 Jan 2016 14:21:09 +0000 Subject: Type class for sanity In-Reply-To: <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> Message-ID: <54f04e1ba120419789a3a40337df782c@AM3PR30MB019.064d.mgd.msft.net> I?m a bit dubious about whether it?s worth the effort of making this an extension that requires GHC support. Does the gain justify the (maybe-small but eternal) pain Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg Sent: 25 January 2016 14:06 To: David Feuer Cc: Haskell Libraries ; ghc-devs Subject: Re: Type class for sanity Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for someone and going all the way to nf would be less efficient / impossible. Richard On Jan 25, 2016, at 8:44 AM, David Feuer > wrote: I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? On Jan 25, 2016 7:34 AM, "Richard Eisenberg" > wrote: +1 This would be very easy to implement, too. But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. On Jan 24, 2016, at 4:24 PM, David Feuer > wrote: > Since type families can be stuck, it's sometimes useful to restrict > things to sane types. At present, the most convenient way I can see to > do this in general is with Typeable: > > type family Foo x where > Foo 'True = Int > > class Typeable (Foo x) => Bar x where > blah :: proxy x -> Foo x > > This will prevent anyone from producing the bogus instance > > instance Bar 'False where > blah _ = undefined > > Unfortunately, the Typeable constraint carries runtime overhead. One > possible way around this, I think, is with a class that does just > sanity checking and nothing more: > > class Sane (a :: k) > instance Sane Int > instance Sane Char > instance Sane 'False > instance Sane 'True > instance Sane '[] > instance Sane '(:) > instance Sane (->) > instance Sane 'Just > instance Sane 'Nothing > instance (Sane f, Sane x) => Sane (f x) > > To really do its job properly, Sane would need to have instances for > all sane types and no more. An example of an insane instance of Sane > would be > > instance Sane (a :: MyKind) > > which would include stuck types of kind MyKind. > > Would it be useful to add such an automatic-only class to GHC? > > David > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon Jan 25 14:26:09 2016 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 25 Jan 2016 09:26:09 -0500 Subject: Type class for sanity In-Reply-To: <54f04e1ba120419789a3a40337df782c@AM3PR30MB019.064d.mgd.msft.net> References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> <460529F3-2626-4505-B326-C6C6D929C357@cis.upenn.edu> <54f04e1ba120419789a3a40337df782c@AM3PR30MB019.064d.mgd.msft.net> Message-ID: <6E311A34-DB3C-4459-B779-DF670EC2FDD0@cis.upenn.edu> Yes, if we can arrange that Ground a implies that Equals a [a] reduces to False, with type family Equals a b where Equals a a = True Equals a b = False But getting that to work is admittedly a feature beyond what's proposed. On Jan 25, 2016, at 9:21 AM, Simon Peyton Jones wrote: > I?m a bit dubious about whether it?s worth the effort of making this an extension that requires GHC support. Does the gain justify the (maybe-small but eternal) pain > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard Eisenberg > Sent: 25 January 2016 14:06 > To: David Feuer > Cc: Haskell Libraries ; ghc-devs > Subject: Re: Type class for sanity > > Might be nice to have whnf too, while we're at it. Perhaps whnf is enough for someone and going all the way to nf would be less efficient / impossible. > > Richard > > On Jan 25, 2016, at 8:44 AM, David Feuer wrote: > > > I don't care about the name at all. Unstuck? Would we want to distinguish between whnf (e.g., Proxy Any) and nf, or is only nf sufficiently useful? > > On Jan 25, 2016 7:34 AM, "Richard Eisenberg" wrote: > +1 > > This would be very easy to implement, too. > > But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. > > On Jan 24, 2016, at 4:24 PM, David Feuer wrote: > > > Since type families can be stuck, it's sometimes useful to restrict > > things to sane types. At present, the most convenient way I can see to > > do this in general is with Typeable: > > > > type family Foo x where > > Foo 'True = Int > > > > class Typeable (Foo x) => Bar x where > > blah :: proxy x -> Foo x > > > > This will prevent anyone from producing the bogus instance > > > > instance Bar 'False where > > blah _ = undefined > > > > Unfortunately, the Typeable constraint carries runtime overhead. One > > possible way around this, I think, is with a class that does just > > sanity checking and nothing more: > > > > class Sane (a :: k) > > instance Sane Int > > instance Sane Char > > instance Sane 'False > > instance Sane 'True > > instance Sane '[] > > instance Sane '(:) > > instance Sane (->) > > instance Sane 'Just > > instance Sane 'Nothing > > instance (Sane f, Sane x) => Sane (f x) > > > > To really do its job properly, Sane would need to have instances for > > all sane types and no more. An example of an insane instance of Sane > > would be > > > > instance Sane (a :: MyKind) > > > > which would include stuck types of kind MyKind. > > > > Would it be useful to add such an automatic-only class to GHC? > > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wren at community.haskell.org Mon Jan 25 17:27:33 2016 From: wren at community.haskell.org (wren romano) Date: Mon, 25 Jan 2016 12:27:33 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: <56A2BFD6.40705@nh2.me> References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> <56A2BFD6.40705@nh2.me> Message-ID: -1 for changing the Ord Bool instance, due to the likelihood of subtle bugs and regressions. -1 for using the name (==>) due to conflict with QuickCheck, Smallcheck, etc. Ambivalent about adding an implication operator distinct from (<=), mainly because I haven't needed it myself. IMO, the ordering on Bool should be defined so that it coincides with implication, thanks to the relationship to Boolean/Heyting algebras? which the current Ord instance already does. Though I do agree that if implication is given its own name then it ought to be lazy in the second argument, whereas it's not clear that (<=) should share that strictness/laziness. Personally, were I to add something like implication, I'd define it via a type class so that we can unify the things called (==>) in various testing frameworks. Of course, doing this appropriately would mean making a decent hierarchy of type classes for order/lattice theory. But given as we don't have one of those yet, I'd do it in a separate package so it could be played around with until everything fits together nicely, and then aim to get it blessed into HP rather than changing base. -- Live well, ~wren From wren at community.haskell.org Mon Jan 25 17:33:06 2016 From: wren at community.haskell.org (wren romano) Date: Mon, 25 Jan 2016 12:33:06 -0500 Subject: Type class for sanity In-Reply-To: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> Message-ID: On Mon, Jan 25, 2016 at 7:34 AM, Richard Eisenberg wrote: > But I suggest a different name. Ground? Terminating? NormalForm? Irreducible? ValueType? I don't love any of these, but I love Sane less. I'm also strongly opposed to using "sane". That name is ableist and quite offputting to many Haskellers I know (myself included). To say nothing of the fact that the name doesn't provide any useful understanding of what precisely it's supposed to be categorizing. -- Live well, ~wren From david.feuer at gmail.com Mon Jan 25 17:35:13 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 25 Jan 2016 12:35:13 -0500 Subject: Type class for sanity In-Reply-To: References: <18F29A7D-2691-47CE-AC2B-12BEC943A4CD@cis.upenn.edu> Message-ID: You're correct. Please forget that name. On Jan 25, 2016 12:33 PM, "wren romano" wrote: > On Mon, Jan 25, 2016 at 7:34 AM, Richard Eisenberg > wrote: > > But I suggest a different name. Ground? Terminating? NormalForm? > Irreducible? ValueType? I don't love any of these, but I love Sane less. > > I'm also strongly opposed to using "sane". That name is ableist and > quite offputting to many Haskellers I know (myself included). To say > nothing of the fact that the name doesn't provide any useful > understanding of what precisely it's supposed to be categorizing. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Jan 26 15:23:00 2016 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 26 Jan 2016 10:23:00 -0500 Subject: Proposal: Data.Bool.implies In-Reply-To: References: <569C4B48.6060507@nh2.me> <56A13175.8090502@gmail.com> <56A2BFD6.40705@nh2.me> Message-ID: I don't care one way or the other about the creation of implies, I'm happy to bow to popular opinion either way. I do care about changing the strictness of the comparisons in Ord Bool, however, and that would require a rather massive survey of what breaks, and what gets slower -- one that we simply haven't done -- before I'd even start to be comfortable with it. -Edward On Mon, Jan 25, 2016 at 12:27 PM, wren romano wrote: > -1 for changing the Ord Bool instance, due to the likelihood of subtle > bugs and regressions. > > -1 for using the name (==>) due to conflict with QuickCheck, Smallcheck, > etc. > > Ambivalent about adding an implication operator distinct from (<=), > mainly because I haven't needed it myself. IMO, the ordering on Bool > should be defined so that it coincides with implication, thanks to the > relationship to Boolean/Heyting algebras? which the current Ord > instance already does. Though I do agree that if implication is given > its own name then it ought to be lazy in the second argument, whereas > it's not clear that (<=) should share that strictness/laziness. > > Personally, were I to add something like implication, I'd define it > via a type class so that we can unify the things called (==>) in > various testing frameworks. Of course, doing this appropriately would > mean making a decent hierarchy of type classes for order/lattice > theory. But given as we don't have one of those yet, I'd do it in a > separate package so it could be played around with until everything > fits together nicely, and then aim to get it blessed into HP rather > than changing base. > > -- > Live well, > ~wren > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tamarindcode at gmail.com Wed Jan 27 10:37:53 2016 From: tamarindcode at gmail.com (tamarind code) Date: Wed, 27 Jan 2016 10:37:53 +0000 Subject: Cabal on Mac OSX EL Capitan - forwarding DYLD_LIBRARY_PATH Message-ID: Hi, There was a discussion in github about stack (see link below) where the conclusion seems to be pointing towards a bug in Cabal on Mac OSX EL Capitan related to forwarding DYLD_LIBRARY_PATH https://github.com/commercialhaskell/stack/issues/1161#issuecomment-158473975 At the moment the suggested workaround is to disable System Integrity Protection which sounds a bit scary to me. So I thought this might be a good idea to reported to someone in a Cabal team. At the moment I am using an Ubuntu Virtual Machine to avoid having to mess with SIP on my mac. Hope some clever/kind person from the Haskell community would be able to fix this soon. Thanks Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Wed Jan 27 10:57:44 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 27 Jan 2016 11:57:44 +0100 Subject: Cabal on Mac OSX EL Capitan - forwarding DYLD_LIBRARY_PATH In-Reply-To: (tamarind code's message of "Wed, 27 Jan 2016 10:37:53 +0000") References: Message-ID: <87mvrrcms7.fsf@gmail.com> On 2016-01-27 at 11:37:53 +0100, tamarind code wrote: > There was a discussion in github about stack (see link below) where the > conclusion seems to be pointing towards a bug in Cabal on Mac OSX EL > Capitan related to forwarding DYLD_LIBRARY_PATH Is this really a bug *in Cabal*? Or is this rather a newly introduced OS limitation of El Capitan, which may even be in conflict with the POSIX specs. Quoting[1]: > Spawning children processes of processes restricted by System > Integrity Protection, such as by launching a helper process in a > bundle with NSTask or calling the exec(2) command, resets the Mach > special ports of that child process. Any dynamic linker (dyld) > environment variables, such as DYLD_LIBRARY_PATH, are purged when > launching protected processes. So OSX deliberately interferes with environment-variable inheritance. So what is Cabal even supposed to do here? This also seems like a rather radical change, which will have probably broken a lot of other software projects relying that DYLD_LIBRARY_PATH is inherited throughout process creations. [1]: https://developer.apple.com/library/prerelease/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html#//apple_ref/doc/uid/TP40016462-CH3-SW1 From asr at eafit.edu.co Sat Jan 30 05:19:46 2016 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Sat, 30 Jan 2016 00:19:46 -0500 Subject: Bug tracker for cpphs Message-ID: Hi Malcolm, (I'm resending my old question to the libraries mailing list) Is there a bug tracker for cpphs? Best, -- Andr?s From malcolm.wallace at me.com Sat Jan 30 11:49:09 2016 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Sat, 30 Jan 2016 11:49:09 +0000 Subject: Bug tracker for cpphs In-Reply-To: References: Message-ID: <82C424EA-3788-4BB2-AA2E-8A6B8BAE7A7D@me.com> On 30 Jan 2016, at 05:19, Andr?s Sicard-Ram?rez wrote: > Is there a bug tracker for cpphs? Sorry, no. I know it is a bit old-school to accept only email reports of bugs, not least because it gives little visibility to the world at large about which bugs are known, and if they are being fixed or not. But I never found a ticketing system I liked, and the effort required to set up a tracker always seems greater than the value it might deliver for a small project like cpphs. If someone with more experience of setting up trackers were to do the work of creating one for cpphs (maybe on github? is that where everyone hangs out these days?), I might be persuaded to use it. :-) Regards, Malcolm From asr at eafit.edu.co Sat Jan 30 20:17:32 2016 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Sat, 30 Jan 2016 15:17:32 -0500 Subject: Bug tracker for cpphs In-Reply-To: <82C424EA-3788-4BB2-AA2E-8A6B8BAE7A7D@me.com> References: <82C424EA-3788-4BB2-AA2E-8A6B8BAE7A7D@me.com> Message-ID: Hi Malcolm, On 30 January 2016 at 06:49, Malcolm Wallace wrote: > If someone with more experience of setting up trackers were to do the work of creating one for cpphs (maybe on github? is that where everyone hangs out these days?), I might be persuaded to use it. :-) To you set up a bug tracker in GitHub for cpphs requires only two steps: 1. Create a GitHub account (you already have one) 2. Create the cpphs repository with the issues enabled. Best, -- Andr?s From tanuki at gmail.com Sun Jan 31 00:35:23 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Sat, 30 Jan 2016 16:35:23 -0800 Subject: Fwd: Bug tracker for cpphs In-Reply-To: References: <82C424EA-3788-4BB2-AA2E-8A6B8BAE7A7D@me.com> Message-ID: Chiming in to agree: don't be afraid of Github, it's very ergonomic. In particular, it's safe to only look at the bits relevant to your immediate needs; you don't have to know the whole system before doing anything. On Sat, Jan 30, 2016 at 12:17 PM, Andr?s Sicard-Ram?rez wrote: > Hi Malcolm, > > On 30 January 2016 at 06:49, Malcolm Wallace > wrote: > > If someone with more experience of setting up trackers were to do the > work of creating one for cpphs (maybe on github? is that where everyone > hangs out these days?), I might be persuaded to use it. :-) > > To you set up a bug tracker in GitHub for cpphs requires only two steps: > > 1. Create a GitHub account (you already have one) > 2. Create the cpphs repository with the issues enabled. > > Best, > > -- > Andr?s > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Sun Jan 31 00:40:41 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 30 Jan 2016 18:40:41 -0600 Subject: Bug tracker for cpphs In-Reply-To: References: <82C424EA-3788-4BB2-AA2E-8A6B8BAE7A7D@me.com> Message-ID: If you want something lightweight that'll just send you emails when an issue is filed (thus enabling you to not change your workflow), then GitHub issues are probably tops right now. You can get into more advanced categorization, search, and filtering of issues but you're not obligated to do anything upfront and it can happen incrementally over time. All to say, I agree with Theodore and Andres even if I have my reservations about using a proprietary service for open source work. On Sat, Jan 30, 2016 at 6:35 PM, Theodore Lief Gannon wrote: > Chiming in to agree: don't be afraid of Github, it's very ergonomic. In > particular, it's safe to only look at the bits relevant to your immediate > needs; you don't have to know the whole system before doing anything. > > On Sat, Jan 30, 2016 at 12:17 PM, Andr?s Sicard-Ram?rez > wrote: > >> Hi Malcolm, >> >> On 30 January 2016 at 06:49, Malcolm Wallace >> wrote: >> > If someone with more experience of setting up trackers were to do the >> work of creating one for cpphs (maybe on github? is that where everyone >> hangs out these days?), I might be persuaded to use it. :-) >> >> To you set up a bug tracker in GitHub for cpphs requires only two steps: >> >> 1. Create a GitHub account (you already have one) >> 2. Create the cpphs repository with the issues enabled. >> >> Best, >> >> -- >> Andr?s >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sun Jan 31 17:05:02 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 31 Jan 2016 18:05:02 +0100 (CET) Subject: Bug tracker for cpphs In-Reply-To: References: <82C424EA-3788-4BB2-AA2E-8A6B8BAE7A7D@me.com> Message-ID: > On 30 January 2016 at 06:49, Malcolm Wallace wrote: >> If someone with more experience of setting up trackers were to do the work of creating one for cpphs (maybe on github? is that where everyone hangs out these days?), I might be persuaded to use it. :-) Btw. hub.darcs.net has a bug tracker, too.