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: