From ndospark320 at naver.com Wed May 2 12:44:44 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Wed, 02 May 2018 21:44:44 +0900
Subject: =?utf-8?B?SW5zdGFuY2Ugb2YgYFNlbWlncm91cCAoRWl0aGVyIGEgYilgIG5lZWRzIHRvIGJlIGV2ZQ==?=
=?utf-8?B?bnR1YWxseSBjaGFuZ2VkLg==?=
Message-ID: <4c6c2e4f6a6b6b56e0f1872f312caa7@cweb03.nm.nhnsystem.com>
Now since `base` package version `4.11.0.0`, `Monoid` is a subclass of `Semigroup`. And that made `Monoid (Either a b)` instance impossible to exist.
Current (`4.11.0.1`) instance of `Semigroup (Either a b)` (excluding `stimes`:
{{{#!hs
-- | @since 4.9.0.0
instance Semigroup (Either a b) where
Left _ <> b = b
a <> _ = a
}}}
No value of `Either a b` can be `mempty`.
This must be eventually changed to:
{{{#!hs
instance Semigroup a => Semigroup (Either a b) where
Left a <> Left b = Left (a <> b)
Left _ <> b = b
a <> _ = a
}}}
The former behavior can be made with `Either (Last a) b`.
This makes `Monoid (Either a b)` possible:
{{{#!hs
instance Monoid a => Monoid (Either a b) where
mempty = Left mempty
}}}
Also `Alternative (Either e)`:
{{{#!hs
instance Monoid e => Alternative (Either e) where
empty = mempty
(<|>) = (<>)
}}}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ndospark320 at naver.com Wed May 2 14:31:55 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Wed, 02 May 2018 23:31:55 +0900
Subject: =?utf-8?B?TW9ub2lkIG92ZXIgWE9SIG9yIFhOT1IsIGFuZCBNb25vaWQgbGlmdGVkIGJ5IEFwcGxpYw==?=
=?utf-8?B?YXRpdmUu?=
Message-ID: <4664b84458b828b68b9b5e92fde9b3@cweb09.nm.nhnsystem.com>
Logical XOR is associative, also is XNOR. And they both have an identity element.
Hence:
newtype Even = Even {getEven :: Bool}
newtype Odd = Odd {getOdd :: Bool}
instance Semigroup Even where
(<>) = (==) -- (==) over Bool == Logical XNOR
instance Semigroup Odd where
(<>) = (/=) -- (/=) over Bool == Logical XOR
instance Monoid Even where
mempty = True
instance Monoid Odd where
mempty = False
So foldMap would determine the parity of the number of Trues.
Also, Monoid lifted by Applicative is also Monoid. This might be useful:
newtype AMonoid f a = AMonoid {getAMonoid :: f a}
instance (Applicative f, Semigroup a) => Semigroup (AMonoid f a) where
(<>) = liftA2 (<>)
instance (Applicative f, Monoid a) => Monoid (AMonoid f a) where
mempty = pure mempty
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From andrew.thaddeus at gmail.com Wed May 2 14:34:26 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Wed, 2 May 2018 10:34:26 -0400
Subject: Monoid over XOR or XNOR, and Monoid lifted by Applicative.
In-Reply-To: <4664b84458b828b68b9b5e92fde9b3@cweb09.nm.nhnsystem.com>
References: <4664b84458b828b68b9b5e92fde9b3@cweb09.nm.nhnsystem.com>
Message-ID:
I agree that the AMonoid type you describe is useful. In fact, it's going
to be in base when GHC 8.6 is released: https://github.com/ghc/ghc/pull/123
On Wed, May 2, 2018 at 10:31 AM, 박신환 wrote:
> Logical XOR is associative, also is XNOR. And they both have an identity
> element.
>
>
>
> Hence:
>
>
>
> newtype Even = Even {getEven :: Bool}
>
> newtype Odd = Odd {getOdd :: Bool}
>
>
>
> instance Semigroup Even where
>
> (<>) = (==) -- (==) over Bool == Logical XNOR
>
>
>
> instance Semigroup Odd where
>
> (<>) = (/=) -- (/=) over Bool == Logical XOR
>
>
>
> instance Monoid Even where
>
> mempty = True
>
>
>
> instance Monoid Odd where
>
> mempty = False
>
>
>
> So foldMap would determine the parity of the number of Trues.
>
>
>
>
>
> Also, Monoid lifted by Applicative is also Monoid. This might be useful:
>
>
>
> newtype AMonoid f a = AMonoid {getAMonoid :: f a}
>
>
>
> instance (Applicative f, Semigroup a) => Semigroup (AMonoid f a) where
>
> (<>) = liftA2 (<>)
>
>
>
> instance (Applicative f, Monoid a) => Monoid (AMonoid f a) where
>
> mempty = pure mempty
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
--
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ndospark320 at naver.com Thu May 3 09:22:16 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Thu, 03 May 2018 18:22:16 +0900
Subject: =?utf-8?B?TW9ub2lkIGZvciBaaXBMaXN0?=
Message-ID:
As instance Alternative ZipList is defined since 4.11.0.0:
instanceAlternativeZipListwhereempty=ZipList[]ZipList<|>ZipList=ZipList(xs++drop(lengthxs)ys)
It seems perfectly fine to make Monoid for ZipList as followings:
instance Semigroup a => Semigroup (ZipList a) where
ZipList [] <> ZipList ys = ZipList ys
ZipList xs <> ZipList [] = ZipList xs
ZipList (x:xs) <> ZipList (y:ys) = ZipList (x <> y : ZipList xs <> ZipList ys)
instance Semigroup a => Monoid (ZipList a) where
mempty = ZipList []
Note that this semantic is similar to that of Maybe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From andrew.thaddeus at gmail.com Thu May 3 12:05:24 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Thu, 3 May 2018 08:05:24 -0400
Subject: Monoid for ZipList
In-Reply-To:
References:
Message-ID:
There is another possible instance. We can instead write:
instance Semigroup a => Semigroup (ZipList a) where
(<>) = liftA2 (<>)
instance Monoid a => Monoid (ZipList a) where
mempty = pure mempty
This behaves differently, and it is also law-abiding.
On Thu, May 3, 2018 at 5:22 AM, 박신환 wrote:
> As *instance Alternative ZipList* is defined since 4.11.0.0:
>
> *instance Alternative ZipList where
> empty = ZipList []
> ZipList xs <|> ZipList ys = ZipList (xs ++ drop (length xs ) ys *
> *)*
> It seems perfectly fine to make *Monoid* for *ZipList* as followings:
>
>
>
>
>
>
>
> *instance Semigroup a => Semigroup (ZipList a) where ZipList [] <> ZipList ys = ZipList ys ZipList xs <> ZipList [] = ZipList xs ZipList (x:xs) <> ZipList (y:ys) = ZipList (x <> y : ZipList xs <> ZipList ys)instance Semigroup a => Monoid (ZipList a) where mempty = ZipList []*
>
> Note that this semantic is similar to that of *Maybe*.
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
--
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From gershomb at gmail.com Thu May 3 15:57:27 2018
From: gershomb at gmail.com (Gershom B)
Date: Thu, 3 May 2018 11:57:27 -0400
Subject: Proposal: add a foldable law
Message-ID:
This came up before (see the prior thread):
https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
The thread at that time grew rather large, and only at the end did I
come up with what I continue to think is a satisfactory formulation of
the law.
However, at that point nobody really acted to do anything about it.
I would like to _formally request that the core libraries committee
review_ the final version of the law as proposed, for addition to
Foldable documentation:
==
Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
Ord), where GenericSet is otherwise fully abstract:
forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
maybe True (`Foldable.elem` x) (g x) =/= False
==
The intuition is: "there is no general way to get an `a` out of `f a`
which cannot be seen by the `Foldable` instance". The use of
`GenericSet` is to handle the case of GADTs, since even parametric
polymorphic functions on them may at given _already known_ types have
specific behaviors.
This law also works over infinite structures.
It rules out "obviously wrong" instances and accepts all the instances
we want to that I am aware of.
My specific motivation for raising this again is that I am rather
tired of people saying "well, Foldable has no laws, and it is in base,
so things without laws are just fine." Foldable does a have a law we
all know to obey. It just has been rather tricky to state. The above
provides a decent way to state it. So we should state it.
Cheers,
Gershom
From ndospark320 at naver.com Thu May 3 23:40:44 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Fri, 04 May 2018 08:40:44 +0900
Subject: =?utf-8?B?UmU6IE1vbm9pZCBmb3IgWmlwTGlzdA==?=
In-Reply-To: <2a39c3ed6652c56e115bbb7f1f80871@cweb01.nm.nhnsystem.com>
References:
<2a39c3ed6652c56e115bbb7f1f80871@cweb01.nm.nhnsystem.com>
Message-ID:
I aim to make the semantic consistent compared to that of other type classes (here Maybe).
Also note that your instance is identical to upcoming Ap, as Ap (ZipList a). I also aim to make Monoids as diverse as possible.
-----Original Message-----
From: "Andrew Martin"
To: "박신환";
Cc: "Haskell Libraries";
Sent: 2018-05-03 (목) 21:05:24
Subject: Re: Monoid for ZipList
There is another possible instance. We can instead write:
instance Semigroup a => Semigroup (ZipList a) where
(<>) = liftA2 (<>)
instance Monoid a => Monoid (ZipList a) where
mempty = pure mempty
This behaves differently, and it is also law-abiding.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Fri May 4 22:04:05 2018
From: ekmett at gmail.com (Edward Kmett)
Date: Fri, 4 May 2018 18:04:05 -0400
Subject: Monoid for ZipList
In-Reply-To:
References:
<2a39c3ed6652c56e115bbb7f1f80871@cweb01.nm.nhnsystem.com>
Message-ID: <07FFD10B-93A0-47BF-92DC-0893392FFD8D@gmail.com>
It is worth noting that Maybe a and [a] are rather special cases. The former is the monoid you get from adjoining a unit to a semigroup. The latter is the free monoid. Most other monoids for things wrapped in an applicative are either based on the Alternative instance which inherently provides a monoidal structure or based on lifting a monoid pointwise into the data type.
Here we have at least 3-4 possible, quite reasonable, monoids at play, and no real reason to choose any one of them over the others. In that situation, our general practice thus far has been to resist choosing if a choice hasn't already been made, simply because there is no real manner other than memorization / code inspection for a user to know which instance we happened to pick.
I'm -1 on adding the instance proposed here.
Sent from my iPhone
> On May 3, 2018, at 7:40 PM, 박신환 wrote:
>
> I aim to make the semantic consistent compared to that of other type classes (here Maybe).
>
> Also note that your instance is identical to upcoming Ap, as Ap (ZipList a). I also aim to make Monoids as diverse as possible.
>
>
> -----Original Message-----
> From: "Andrew Martin"
> To: "박신환";
> Cc: "Haskell Libraries";
> Sent: 2018-05-03 (목) 21:05:24
> Subject: Re: Monoid for ZipList
>
> There is another possible instance. We can instead write:
>
> instance Semigroup a => Semigroup (ZipList a) where
> (<>) = liftA2 (<>)
> instance Monoid a => Monoid (ZipList a) where
> mempty = pure mempty
>
> This behaves differently, and it is also law-abiding.
>
> _______________________________________________
> 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 ndospark320 at naver.com Sat May 5 07:38:33 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Sat, 05 May 2018 16:38:33 +0900
Subject: =?utf-8?B?UmU6IE1vbm9pZCBmb3IgWmlwTGlzdA==?=
In-Reply-To: <07FFD10B-93A0-47BF-92DC-0893392FFD8D@gmail.com>
References:
<2a39c3ed6652c56e115bbb7f1f80871@cweb01.nm.nhnsystem.com>
<07FFD10B-93A0-47BF-92DC-0893392FFD8D@gmail.com>
Message-ID: <1fd0da4c12183d7d273e2a5a36d24697@cweb20.nm.nhnsystem.com>
I'm not refering that Maybe makes Monoid by adding the identity element. I'm refering that the Monoid (Maybe (First a)) have the same semantic as Alternative Maybe.
So I'm suggesting that the same semantic should go to Monoid (ZipList (First a)) for Alternative ZipList.
-----Original Message-----
From: "Edward Kmett"
To: "박신환";
Cc: "Haskell Libraries";
Sent: 2018-05-05 (토) 07:04:05
Subject: Re: Monoid for ZipList
It is worth noting that Maybe a and [a] are rather special cases. The former is the monoid you get from adjoining a unit to a semigroup. The latter is the free monoid. Most other monoids for things wrapped in an applicative are either based on the Alternative instance which inherently provides a monoidal structure or based on lifting a monoid pointwise into the data type.
Here we have at least 3-4 possible, quite reasonable, monoids at play, and no real reason to choose any one of them over the others. In that situation, our general practice thus far has been to resist choosing if a choice hasn't already been made, simply because there is no real manner other than memorization / code inspection for a user to know which instance we happened to pick.
I'm -1 on adding the instance proposed here.
Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ekmett at gmail.com Sat May 5 18:31:02 2018
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 5 May 2018 14:31:02 -0400
Subject: Monoid over XOR or XNOR, and Monoid lifted by Applicative.
In-Reply-To: <4664b84458b828b68b9b5e92fde9b3@cweb09.nm.nhnsystem.com>
References: <4664b84458b828b68b9b5e92fde9b3@cweb09.nm.nhnsystem.com>
Message-ID:
In that same light, we're also missing packaged monoids for the bitwise
(.|.), (.&.), xor (and the non-existent xnor) from Data.Bits. Bool is an
instance of Bits. Extending this to these more general types you'd get:
newtype And a = And { getAnd :: a }
newtype Or a = Or { getOr :: a }
newtype Even a = Even { getEven :: a }
newtype Odd a = Odd { getOdd :: a }
Once things move to arbitrary bitwise operations, Even/Odd may not be the
best names, though they do perform "vertical" bitwise parity checks.
While I don't have a particularly strong preference about whether those
extra instances should live in Data.Monoid or Data.Bits, due to Monoid now
being in Prelude, users do import Data.Monoid unqualified in rather more
code than Bits. This would give me a slight preference to placing these in
Data.Bits, but if one or the other would create an import cycle in base, I
think it'd be fine to let that trump such a concern and force the placement.
-Edward
On Wed, May 2, 2018 at 10:31 AM, 박신환 wrote:
> Logical XOR is associative, also is XNOR. And they both have an identity
> element.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From m.farkasdyck at gmail.com Sat May 5 20:54:55 2018
From: m.farkasdyck at gmail.com (Matthew Farkas-Dyck)
Date: Sat, 5 May 2018 12:54:55 -0800
Subject: Monoid over XOR or XNOR, and Monoid lifted by Applicative.
In-Reply-To:
References: <4664b84458b828b68b9b5e92fde9b3@cweb09.nm.nhnsystem.com>
Message-ID:
On 5/5/18, Edward Kmett wrote:
> In that same light, we're also missing packaged monoids for the bitwise
> (.|.), (.&.), xor (and the non-existent xnor) from Data.Bits.
I defined a `BitSet` type in my alg package:
http://hackage.haskell.org/package/alg
(Building docs failed, so here is the definition: `newtype BitSet a =
BitSet { bits :: a }`)
The `Monoid` instance is (`False`, `xor`) (wasn't thinking about xnor,
stupid me).
I was also trying to define `Monoid` instances for `Min (BitSet a)`
and `Max (BitSet a)` but alas, they overlap, tho `BitSet` is not `Ord`
(so usual instances are useless).
Maybe we want a `Lattice` class?
From david.feuer at gmail.com Sat May 5 21:09:16 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 05 May 2018 21:09:16 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
I have another idea that might be worth considering. I think it's a lot
simpler than yours.
Law: If t is a Foldable instance, then there must exist:
1. A Traversable instance u and
2. An injective function
toTrav :: t a -> u a
Such that
foldMap @t = foldMapDefault . toTrav
I'm pretty sure this gets at the point you're trying to make.
On May 3, 2018 11:58 AM, "Gershom B" wrote:
This came up before (see the prior thread):
https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
The thread at that time grew rather large, and only at the end did I
come up with what I continue to think is a satisfactory formulation of
the law.
However, at that point nobody really acted to do anything about it.
I would like to _formally request that the core libraries committee
review_ the final version of the law as proposed, for addition to
Foldable documentation:
==
Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
Ord), where GenericSet is otherwise fully abstract:
forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
maybe True (`Foldable.elem` x) (g x) =/= False
==
The intuition is: "there is no general way to get an `a` out of `f a`
which cannot be seen by the `Foldable` instance". The use of
`GenericSet` is to handle the case of GADTs, since even parametric
polymorphic functions on them may at given _already known_ types have
specific behaviors.
This law also works over infinite structures.
It rules out "obviously wrong" instances and accepts all the instances
we want to that I am aware of.
My specific motivation for raising this again is that I am rather
tired of people saying "well, Foldable has no laws, and it is in base,
so things without laws are just fine." Foldable does a have a law we
all know to obey. It just has been rather tricky to state. The above
provides a decent way to state it. So we should state it.
Cheers,
Gershom
_______________________________________________
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 Sat May 5 21:11:38 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 05 May 2018 21:11:38 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
Actually, requiring injectivity shouldn't be necessary.
On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
> I have another idea that might be worth considering. I think it's a lot
> simpler than yours.
>
> Law: If t is a Foldable instance, then there must exist:
>
> 1. A Traversable instance u and
> 2. An injective function
> toTrav :: t a -> u a
>
> Such that
>
> foldMap @t = foldMapDefault . toTrav
>
> I'm pretty sure this gets at the point you're trying to make.
>
>
> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>
> This came up before (see the prior thread):
> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>
> The thread at that time grew rather large, and only at the end did I
> come up with what I continue to think is a satisfactory formulation of
> the law.
>
> However, at that point nobody really acted to do anything about it.
>
> I would like to _formally request that the core libraries committee
> review_ the final version of the law as proposed, for addition to
> Foldable documentation:
>
> ==
> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
> Ord), where GenericSet is otherwise fully abstract:
>
> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
> maybe True (`Foldable.elem` x) (g x) =/= False
> ==
>
> The intuition is: "there is no general way to get an `a` out of `f a`
> which cannot be seen by the `Foldable` instance". The use of
> `GenericSet` is to handle the case of GADTs, since even parametric
> polymorphic functions on them may at given _already known_ types have
> specific behaviors.
>
> This law also works over infinite structures.
>
> It rules out "obviously wrong" instances and accepts all the instances
> we want to that I am aware of.
>
> My specific motivation for raising this again is that I am rather
> tired of people saying "well, Foldable has no laws, and it is in base,
> so things without laws are just fine." Foldable does a have a law we
> all know to obey. It just has been rather tricky to state. The above
> provides a decent way to state it. So we should state it.
>
> Cheers,
> Gershom
> _______________________________________________
> 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 Sat May 5 21:18:07 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 05 May 2018 21:18:07 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
Let me take that back. Injectivity is necessary. And I meant
foldMap @t f = foldMapDefault f . toTrav
On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
> Actually, requiring injectivity shouldn't be necessary.
>
> On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
>
>> I have another idea that might be worth considering. I think it's a lot
>> simpler than yours.
>>
>> Law: If t is a Foldable instance, then there must exist:
>>
>> 1. A Traversable instance u and
>> 2. An injective function
>> toTrav :: t a -> u a
>>
>> Such that
>>
>> foldMap @t = foldMapDefault . toTrav
>>
>> I'm pretty sure this gets at the point you're trying to make.
>>
>>
>> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>>
>> This came up before (see the prior thread):
>> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>>
>> The thread at that time grew rather large, and only at the end did I
>> come up with what I continue to think is a satisfactory formulation of
>> the law.
>>
>> However, at that point nobody really acted to do anything about it.
>>
>> I would like to _formally request that the core libraries committee
>> review_ the final version of the law as proposed, for addition to
>> Foldable documentation:
>>
>> ==
>> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
>> Ord), where GenericSet is otherwise fully abstract:
>>
>> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
>> maybe True (`Foldable.elem` x) (g x) =/= False
>> ==
>>
>> The intuition is: "there is no general way to get an `a` out of `f a`
>> which cannot be seen by the `Foldable` instance". The use of
>> `GenericSet` is to handle the case of GADTs, since even parametric
>> polymorphic functions on them may at given _already known_ types have
>> specific behaviors.
>>
>> This law also works over infinite structures.
>>
>> It rules out "obviously wrong" instances and accepts all the instances
>> we want to that I am aware of.
>>
>> My specific motivation for raising this again is that I am rather
>> tired of people saying "well, Foldable has no laws, and it is in base,
>> so things without laws are just fine." Foldable does a have a law we
>> all know to obey. It just has been rather tricky to state. The above
>> provides a decent way to state it. So we should state it.
>>
>> Cheers,
>> Gershom
>> _______________________________________________
>> 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 Sat May 5 21:51:06 2018
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 5 May 2018 17:51:06 -0400
Subject: Monoid over XOR or XNOR, and Monoid lifted by Applicative.
In-Reply-To:
References: <4664b84458b828b68b9b5e92fde9b3@cweb09.nm.nhnsystem.com>
Message-ID:
There are several packagings of lattices and semilattices strewn across hackage, and not much convergence on any single one.
Sent from my iPhone
> On May 5, 2018, at 4:54 PM, Matthew Farkas-Dyck wrote:
>
>> On 5/5/18, Edward Kmett wrote:
>> In that same light, we're also missing packaged monoids for the bitwise
>> (.|.), (.&.), xor (and the non-existent xnor) from Data.Bits.
>
> I defined a `BitSet` type in my alg package:
> http://hackage.haskell.org/package/alg
> (Building docs failed, so here is the definition: `newtype BitSet a =
> BitSet { bits :: a }`)
>
> The `Monoid` instance is (`False`, `xor`) (wasn't thinking about xnor,
> stupid me).
>
> I was also trying to define `Monoid` instances for `Min (BitSet a)`
> and `Max (BitSet a)` but alas, they overlap, tho `BitSet` is not `Ord`
> (so usual instances are useless).
>
> Maybe we want a `Lattice` class?
From gershomb at gmail.com Sat May 5 22:13:51 2018
From: gershomb at gmail.com (Gershom B)
Date: Sat, 5 May 2018 18:13:51 -0400
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
Hmm… I think this works, and specifies the same law. Nice. Assuming I’m not wrong about that, I’m happy with either version, and will leave it to the committee to decide.
Best,
Gershom
On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com) wrote:
Let me take that back. Injectivity is necessary. And I meant
foldMap @t f = foldMapDefault f . toTrav
On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
Actually, requiring injectivity shouldn't be necessary.
On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
I have another idea that might be worth considering. I think it's a lot simpler than yours.
Law: If t is a Foldable instance, then there must exist:
1. A Traversable instance u and
2. An injective function
toTrav :: t a -> u a
Such that
foldMap @t = foldMapDefault . toTrav
I'm pretty sure this gets at the point you're trying to make.
On May 3, 2018 11:58 AM, "Gershom B" wrote:
This came up before (see the prior thread):
https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
The thread at that time grew rather large, and only at the end did I
come up with what I continue to think is a satisfactory formulation of
the law.
However, at that point nobody really acted to do anything about it.
I would like to _formally request that the core libraries committee
review_ the final version of the law as proposed, for addition to
Foldable documentation:
==
Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
Ord), where GenericSet is otherwise fully abstract:
forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
maybe True (`Foldable.elem` x) (g x) =/= False
==
The intuition is: "there is no general way to get an `a` out of `f a`
which cannot be seen by the `Foldable` instance". The use of
`GenericSet` is to handle the case of GADTs, since even parametric
polymorphic functions on them may at given _already known_ types have
specific behaviors.
This law also works over infinite structures.
It rules out "obviously wrong" instances and accepts all the instances
we want to that I am aware of.
My specific motivation for raising this again is that I am rather
tired of people saying "well, Foldable has no laws, and it is in base,
so things without laws are just fine." Foldable does a have a law we
all know to obey. It just has been rather tricky to state. The above
provides a decent way to state it. So we should state it.
Cheers,
Gershom
_______________________________________________
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 Sat May 5 22:22:52 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 05 May 2018 22:22:52 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
You'll have to email the committee if you want them to consider anything.
The law I suggested is rather stronger than yours, but I think it's
probably closer to what you really meant. Neither option prevents strange
GADTy instances, but I suspect that's a fundamental limitation of Foldable.
On Sat, May 5, 2018, 6:13 PM Gershom B wrote:
> Hmm… I think this works, and specifies the same law. Nice. Assuming I’m
> not wrong about that, I’m happy with either version, and will leave it to
> the committee to decide.
>
> Best,
> Gershom
>
> On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com) wrote:
>
> Let me take that back. Injectivity is necessary. And I meant
>
> foldMap @t f = foldMapDefault f . toTrav
>
> On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
>
>> Actually, requiring injectivity shouldn't be necessary.
>>
>> On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
>>
>>> I have another idea that might be worth considering. I think it's a lot
>>> simpler than yours.
>>>
>>> Law: If t is a Foldable instance, then there must exist:
>>>
>>> 1. A Traversable instance u and
>>> 2. An injective function
>>> toTrav :: t a -> u a
>>>
>>> Such that
>>>
>>> foldMap @t = foldMapDefault . toTrav
>>>
>>> I'm pretty sure this gets at the point you're trying to make.
>>>
>>>
>>> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>>>
>>> This came up before (see the prior thread):
>>> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>>>
>>> The thread at that time grew rather large, and only at the end did I
>>> come up with what I continue to think is a satisfactory formulation of
>>> the law.
>>>
>>> However, at that point nobody really acted to do anything about it.
>>>
>>> I would like to _formally request that the core libraries committee
>>> review_ the final version of the law as proposed, for addition to
>>> Foldable documentation:
>>>
>>> ==
>>> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
>>> Ord), where GenericSet is otherwise fully abstract:
>>>
>>> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
>>> maybe True (`Foldable.elem` x) (g x) =/= False
>>> ==
>>>
>>> The intuition is: "there is no general way to get an `a` out of `f a`
>>> which cannot be seen by the `Foldable` instance". The use of
>>> `GenericSet` is to handle the case of GADTs, since even parametric
>>> polymorphic functions on them may at given _already known_ types have
>>> specific behaviors.
>>>
>>> This law also works over infinite structures.
>>>
>>> It rules out "obviously wrong" instances and accepts all the instances
>>> we want to that I am aware of.
>>>
>>> My specific motivation for raising this again is that I am rather
>>> tired of people saying "well, Foldable has no laws, and it is in base,
>>> so things without laws are just fine." Foldable does a have a law we
>>> all know to obey. It just has been rather tricky to state. The above
>>> provides a decent way to state it. So we should state it.
>>>
>>> Cheers,
>>> Gershom
>>> _______________________________________________
>>> 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 gershomb at gmail.com Sat May 5 22:44:56 2018
From: gershomb at gmail.com (Gershom B)
Date: Sat, 5 May 2018 15:44:56 -0700
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
As per: https://wiki.haskell.org/Core_Libraries_Committee emailing
libraries@ should suffice. But in the case it doesn’t, I’m now ccing the
committee alias directly as well.
The law you suggested does not seem to be generally stronger than mine, but
I would be interested in a counterexample if you can produce one[1]. I
agree that “strange GADTy instances” are not ruled out, but I’m not sure if
I’d consider it a limitation of Foldable, but more a characteristic of
GADTs that isn’t per-se wrong, although it sometimes is counterintuitive :-)
Best,
Gershom
[1] If one is to be found, one would think it’d have to do with GADTs. But
I think GADTs are flexible enough that one could still provide an injection
from a GADT without traversable GADT with traversable such that whatever
weird stuff occurs in the former still occurs in the latter.
On May 5, 2018 at 6:23:04 PM, David Feuer (david.feuer at gmail.com) wrote:
You'll have to email the committee if you want them to consider anything.
The law I suggested is rather stronger than yours, but I think it's
probably closer to what you really meant. Neither option prevents strange
GADTy instances, but I suspect that's a fundamental limitation of Foldable.
On Sat, May 5, 2018, 6:13 PM Gershom B wrote:
> Hmm… I think this works, and specifies the same law. Nice. Assuming I’m
> not wrong about that, I’m happy with either version, and will leave it to
> the committee to decide.
>
> Best,
> Gershom
>
> On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com) wrote:
>
> Let me take that back. Injectivity is necessary. And I meant
>
> foldMap @t f = foldMapDefault f . toTrav
>
> On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
>
>> Actually, requiring injectivity shouldn't be necessary.
>>
>> On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
>>
>>> I have another idea that might be worth considering. I think it's a lot
>>> simpler than yours.
>>>
>>> Law: If t is a Foldable instance, then there must exist:
>>>
>>> 1. A Traversable instance u and
>>> 2. An injective function
>>> toTrav :: t a -> u a
>>>
>>> Such that
>>>
>>> foldMap @t = foldMapDefault . toTrav
>>>
>>> I'm pretty sure this gets at the point you're trying to make.
>>>
>>>
>>> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>>>
>>> This came up before (see the prior thread):
>>> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>>>
>>> The thread at that time grew rather large, and only at the end did I
>>> come up with what I continue to think is a satisfactory formulation of
>>> the law.
>>>
>>> However, at that point nobody really acted to do anything about it.
>>>
>>> I would like to _formally request that the core libraries committee
>>> review_ the final version of the law as proposed, for addition to
>>> Foldable documentation:
>>>
>>> ==
>>> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
>>> Ord), where GenericSet is otherwise fully abstract:
>>>
>>> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
>>> maybe True (`Foldable.elem` x) (g x) =/= False
>>> ==
>>>
>>> The intuition is: "there is no general way to get an `a` out of `f a`
>>> which cannot be seen by the `Foldable` instance". The use of
>>> `GenericSet` is to handle the case of GADTs, since even parametric
>>> polymorphic functions on them may at given _already known_ types have
>>> specific behaviors.
>>>
>>> This law also works over infinite structures.
>>>
>>> It rules out "obviously wrong" instances and accepts all the instances
>>> we want to that I am aware of.
>>>
>>> My specific motivation for raising this again is that I am rather
>>> tired of people saying "well, Foldable has no laws, and it is in base,
>>> so things without laws are just fine." Foldable does a have a law we
>>> all know to obey. It just has been rather tricky to state. The above
>>> provides a decent way to state it. So we should state it.
>>>
>>> Cheers,
>>> Gershom
>>> _______________________________________________
>>> 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 Sat May 5 22:46:42 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 05 May 2018 22:46:42 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
Okay, I'm not actually sure mine is stronger, but it's definitely easier to
understand!
On Sat, May 5, 2018, 6:44 PM Gershom B wrote:
> As per: https://wiki.haskell.org/Core_Libraries_Committee emailing
> libraries@ should suffice. But in the case it doesn’t, I’m now ccing the
> committee alias directly as well.
>
> The law you suggested does not seem to be generally stronger than mine,
> but I would be interested in a counterexample if you can produce one[1]. I
> agree that “strange GADTy instances” are not ruled out, but I’m not sure if
> I’d consider it a limitation of Foldable, but more a characteristic of
> GADTs that isn’t per-se wrong, although it sometimes is counterintuitive :-)
>
> Best,
> Gershom
>
> [1] If one is to be found, one would think it’d have to do with GADTs. But
> I think GADTs are flexible enough that one could still provide an injection
> from a GADT without traversable GADT with traversable such that whatever
> weird stuff occurs in the former still occurs in the latter.
>
> On May 5, 2018 at 6:23:04 PM, David Feuer (david.feuer at gmail.com) wrote:
>
> You'll have to email the committee if you want them to consider anything.
> The law I suggested is rather stronger than yours, but I think it's
> probably closer to what you really meant. Neither option prevents strange
> GADTy instances, but I suspect that's a fundamental limitation of Foldable.
>
> On Sat, May 5, 2018, 6:13 PM Gershom B wrote:
>
>> Hmm… I think this works, and specifies the same law. Nice. Assuming I’m
>> not wrong about that, I’m happy with either version, and will leave it to
>> the committee to decide.
>>
>> Best,
>> Gershom
>>
>> On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com) wrote:
>>
>> Let me take that back. Injectivity is necessary. And I meant
>>
>> foldMap @t f = foldMapDefault f . toTrav
>>
>> On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
>>
>>> Actually, requiring injectivity shouldn't be necessary.
>>>
>>> On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
>>>
>>>> I have another idea that might be worth considering. I think it's a lot
>>>> simpler than yours.
>>>>
>>>> Law: If t is a Foldable instance, then there must exist:
>>>>
>>>> 1. A Traversable instance u and
>>>> 2. An injective function
>>>> toTrav :: t a -> u a
>>>>
>>>> Such that
>>>>
>>>> foldMap @t = foldMapDefault . toTrav
>>>>
>>>> I'm pretty sure this gets at the point you're trying to make.
>>>>
>>>>
>>>> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>>>>
>>>> This came up before (see the prior thread):
>>>> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>>>>
>>>> The thread at that time grew rather large, and only at the end did I
>>>> come up with what I continue to think is a satisfactory formulation of
>>>> the law.
>>>>
>>>> However, at that point nobody really acted to do anything about it.
>>>>
>>>> I would like to _formally request that the core libraries committee
>>>> review_ the final version of the law as proposed, for addition to
>>>> Foldable documentation:
>>>>
>>>> ==
>>>> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
>>>> Ord), where GenericSet is otherwise fully abstract:
>>>>
>>>> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
>>>> maybe True (`Foldable.elem` x) (g x) =/= False
>>>> ==
>>>>
>>>> The intuition is: "there is no general way to get an `a` out of `f a`
>>>> which cannot be seen by the `Foldable` instance". The use of
>>>> `GenericSet` is to handle the case of GADTs, since even parametric
>>>> polymorphic functions on them may at given _already known_ types have
>>>> specific behaviors.
>>>>
>>>> This law also works over infinite structures.
>>>>
>>>> It rules out "obviously wrong" instances and accepts all the instances
>>>> we want to that I am aware of.
>>>>
>>>> My specific motivation for raising this again is that I am rather
>>>> tired of people saying "well, Foldable has no laws, and it is in base,
>>>> so things without laws are just fine." Foldable does a have a law we
>>>> all know to obey. It just has been rather tricky to state. The above
>>>> provides a decent way to state it. So we should state it.
>>>>
>>>> Cheers,
>>>> Gershom
>>>> _______________________________________________
>>>> 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 Sat May 5 22:56:32 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sat, 05 May 2018 22:56:32 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
Ah, actually, I think mine *is* stronger, because it can say more about
infinite structures.
On Sat, May 5, 2018, 6:46 PM David Feuer wrote:
> Okay, I'm not actually sure mine is stronger, but it's definitely easier
> to understand!
>
> On Sat, May 5, 2018, 6:44 PM Gershom B wrote:
>
>> As per: https://wiki.haskell.org/Core_Libraries_Committee emailing
>> libraries@ should suffice. But in the case it doesn’t, I’m now ccing the
>> committee alias directly as well.
>>
>> The law you suggested does not seem to be generally stronger than mine,
>> but I would be interested in a counterexample if you can produce one[1]. I
>> agree that “strange GADTy instances” are not ruled out, but I’m not sure if
>> I’d consider it a limitation of Foldable, but more a characteristic of
>> GADTs that isn’t per-se wrong, although it sometimes is counterintuitive :-)
>>
>> Best,
>> Gershom
>>
>> [1] If one is to be found, one would think it’d have to do with GADTs.
>> But I think GADTs are flexible enough that one could still provide an
>> injection from a GADT without traversable GADT with traversable such that
>> whatever weird stuff occurs in the former still occurs in the latter.
>>
>> On May 5, 2018 at 6:23:04 PM, David Feuer (david.feuer at gmail.com) wrote:
>>
>> You'll have to email the committee if you want them to consider anything.
>> The law I suggested is rather stronger than yours, but I think it's
>> probably closer to what you really meant. Neither option prevents strange
>> GADTy instances, but I suspect that's a fundamental limitation of Foldable.
>>
>> On Sat, May 5, 2018, 6:13 PM Gershom B wrote:
>>
>>> Hmm… I think this works, and specifies the same law. Nice. Assuming I’m
>>> not wrong about that, I’m happy with either version, and will leave it to
>>> the committee to decide.
>>>
>>> Best,
>>> Gershom
>>>
>>> On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com) wrote:
>>>
>>> Let me take that back. Injectivity is necessary. And I meant
>>>
>>> foldMap @t f = foldMapDefault f . toTrav
>>>
>>> On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
>>>
>>>> Actually, requiring injectivity shouldn't be necessary.
>>>>
>>>> On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
>>>>
>>>>> I have another idea that might be worth considering. I think it's a
>>>>> lot simpler than yours.
>>>>>
>>>>> Law: If t is a Foldable instance, then there must exist:
>>>>>
>>>>> 1. A Traversable instance u and
>>>>> 2. An injective function
>>>>> toTrav :: t a -> u a
>>>>>
>>>>> Such that
>>>>>
>>>>> foldMap @t = foldMapDefault . toTrav
>>>>>
>>>>> I'm pretty sure this gets at the point you're trying to make.
>>>>>
>>>>>
>>>>> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>>>>>
>>>>> This came up before (see the prior thread):
>>>>> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>>>>>
>>>>> The thread at that time grew rather large, and only at the end did I
>>>>> come up with what I continue to think is a satisfactory formulation of
>>>>> the law.
>>>>>
>>>>> However, at that point nobody really acted to do anything about it.
>>>>>
>>>>> I would like to _formally request that the core libraries committee
>>>>> review_ the final version of the law as proposed, for addition to
>>>>> Foldable documentation:
>>>>>
>>>>> ==
>>>>> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
>>>>> Ord), where GenericSet is otherwise fully abstract:
>>>>>
>>>>> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
>>>>> maybe True (`Foldable.elem` x) (g x) =/= False
>>>>> ==
>>>>>
>>>>> The intuition is: "there is no general way to get an `a` out of `f a`
>>>>> which cannot be seen by the `Foldable` instance". The use of
>>>>> `GenericSet` is to handle the case of GADTs, since even parametric
>>>>> polymorphic functions on them may at given _already known_ types have
>>>>> specific behaviors.
>>>>>
>>>>> This law also works over infinite structures.
>>>>>
>>>>> It rules out "obviously wrong" instances and accepts all the instances
>>>>> we want to that I am aware of.
>>>>>
>>>>> My specific motivation for raising this again is that I am rather
>>>>> tired of people saying "well, Foldable has no laws, and it is in base,
>>>>> so things without laws are just fine." Foldable does a have a law we
>>>>> all know to obey. It just has been rather tricky to state. The above
>>>>> provides a decent way to state it. So we should state it.
>>>>>
>>>>> Cheers,
>>>>> Gershom
>>>>> _______________________________________________
>>>>> 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 ndospark320 at naver.com Sun May 6 00:40:19 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Sun, 06 May 2018 09:40:19 +0900
Subject: =?utf-8?B?TW9ub2lkIG92ZXIgcmVjaXByb2NhbCBvZiByZWNpcHJvY2FsIHN1bQ==?=
Message-ID:
e.g. Parallel resistors, serial capacitors, parallel inductors.
newtype RecipSum a = RecipSum {getRecipSum :: a}
instance Fractional a => Semigroup (RecipSum a) where
RecipSum x <> RecipSum y = RecipSum (recip (recip x + recip y))
sconcat (x :| xs) = mconcat (x : xs).
stimes n (RecipSum x) = RecipSum (x / fromIntegral n)
instance Fractional a => Monoid (ResipSum a) where
mempty = RecipSum (1 / 0)
mconcat xs = RecipSum (recip . getSum $ foldMap (Sum . recip . getRecipSum) xs)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ndospark320 at naver.com Sun May 6 00:52:09 2018
From: ndospark320 at naver.com (=?utf-8?B?67CV7Iug7ZmY?=)
Date: Sun, 06 May 2018 09:52:09 +0900
Subject: =?utf-8?B?TW9ub2lkIG92ZXIgcmVjaXByb2NhbCBvZiByZWNpcHJvY2FsIHN1bQ==?=
In-Reply-To:
References:
Message-ID: <136648cc88d941528d2192abfd9905f@cweb22.nm.nhnsystem.com>
e.g. Parallel resistors, serial capacitors, parallel inductors.
EDIT: Corrected typo.
newtype RecipSum a = RecipSum {getRecipSum :: a}
instance Fractional a => Semigroup (RecipSum a) where
RecipSum x <> RecipSum y = RecipSum (recip (recip x + recip y))
sconcat (x :| xs) = mconcat (x : xs)
stimes n (RecipSum x) = RecipSum (x / fromIntegral n)
instance Fractional a => Monoid (RecipSum a) where
mempty = RecipSum (1 / 0)
mconcat xs = RecipSum (recip . getSum $ foldMap (Sum . recip . getRecipSum) xs)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Sun May 6 02:18:10 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 06 May 2018 02:18:10 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
My law, unlike yours, also prohibits Foldable IO.
On Sat, May 5, 2018, 6:56 PM David Feuer wrote:
> Ah, actually, I think mine *is* stronger, because it can say more about
> infinite structures.
>
> On Sat, May 5, 2018, 6:46 PM David Feuer wrote:
>
>> Okay, I'm not actually sure mine is stronger, but it's definitely easier
>> to understand!
>>
>> On Sat, May 5, 2018, 6:44 PM Gershom B wrote:
>>
>>> As per: https://wiki.haskell.org/Core_Libraries_Committee emailing
>>> libraries@ should suffice. But in the case it doesn’t, I’m now ccing
>>> the committee alias directly as well.
>>>
>>> The law you suggested does not seem to be generally stronger than mine,
>>> but I would be interested in a counterexample if you can produce one[1]. I
>>> agree that “strange GADTy instances” are not ruled out, but I’m not sure if
>>> I’d consider it a limitation of Foldable, but more a characteristic of
>>> GADTs that isn’t per-se wrong, although it sometimes is counterintuitive :-)
>>>
>>> Best,
>>> Gershom
>>>
>>> [1] If one is to be found, one would think it’d have to do with GADTs.
>>> But I think GADTs are flexible enough that one could still provide an
>>> injection from a GADT without traversable GADT with traversable such that
>>> whatever weird stuff occurs in the former still occurs in the latter.
>>>
>>> On May 5, 2018 at 6:23:04 PM, David Feuer (david.feuer at gmail.com) wrote:
>>>
>>> You'll have to email the committee if you want them to consider
>>> anything. The law I suggested is rather stronger than yours, but I think
>>> it's probably closer to what you really meant. Neither option prevents
>>> strange GADTy instances, but I suspect that's a fundamental limitation of
>>> Foldable.
>>>
>>> On Sat, May 5, 2018, 6:13 PM Gershom B wrote:
>>>
>>>> Hmm… I think this works, and specifies the same law. Nice. Assuming I’m
>>>> not wrong about that, I’m happy with either version, and will leave it to
>>>> the committee to decide.
>>>>
>>>> Best,
>>>> Gershom
>>>>
>>>> On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com)
>>>> wrote:
>>>>
>>>> Let me take that back. Injectivity is necessary. And I meant
>>>>
>>>> foldMap @t f = foldMapDefault f . toTrav
>>>>
>>>> On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
>>>>
>>>>> Actually, requiring injectivity shouldn't be necessary.
>>>>>
>>>>> On Sat, May 5, 2018, 5:09 PM David Feuer
>>>>> wrote:
>>>>>
>>>>>> I have another idea that might be worth considering. I think it's a
>>>>>> lot simpler than yours.
>>>>>>
>>>>>> Law: If t is a Foldable instance, then there must exist:
>>>>>>
>>>>>> 1. A Traversable instance u and
>>>>>> 2. An injective function
>>>>>> toTrav :: t a -> u a
>>>>>>
>>>>>> Such that
>>>>>>
>>>>>> foldMap @t = foldMapDefault . toTrav
>>>>>>
>>>>>> I'm pretty sure this gets at the point you're trying to make.
>>>>>>
>>>>>>
>>>>>> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>>>>>>
>>>>>> This came up before (see the prior thread):
>>>>>> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>>>>>>
>>>>>> The thread at that time grew rather large, and only at the end did I
>>>>>> come up with what I continue to think is a satisfactory formulation of
>>>>>> the law.
>>>>>>
>>>>>> However, at that point nobody really acted to do anything about it.
>>>>>>
>>>>>> I would like to _formally request that the core libraries committee
>>>>>> review_ the final version of the law as proposed, for addition to
>>>>>> Foldable documentation:
>>>>>>
>>>>>> ==
>>>>>> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
>>>>>> Ord), where GenericSet is otherwise fully abstract:
>>>>>>
>>>>>> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
>>>>>> maybe True (`Foldable.elem` x) (g x) =/= False
>>>>>> ==
>>>>>>
>>>>>> The intuition is: "there is no general way to get an `a` out of `f a`
>>>>>> which cannot be seen by the `Foldable` instance". The use of
>>>>>> `GenericSet` is to handle the case of GADTs, since even parametric
>>>>>> polymorphic functions on them may at given _already known_ types have
>>>>>> specific behaviors.
>>>>>>
>>>>>> This law also works over infinite structures.
>>>>>>
>>>>>> It rules out "obviously wrong" instances and accepts all the instances
>>>>>> we want to that I am aware of.
>>>>>>
>>>>>> My specific motivation for raising this again is that I am rather
>>>>>> tired of people saying "well, Foldable has no laws, and it is in base,
>>>>>> so things without laws are just fine." Foldable does a have a law we
>>>>>> all know to obey. It just has been rather tricky to state. The above
>>>>>> provides a decent way to state it. So we should state it.
>>>>>>
>>>>>> Cheers,
>>>>>> Gershom
>>>>>> _______________________________________________
>>>>>> 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 gershomb at gmail.com Sun May 6 02:36:58 2018
From: gershomb at gmail.com (Gershom B)
Date: Sat, 5 May 2018 22:36:58 -0400
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
I think you’re wrong on both counts. The “quantification law” (i.e. what i suggest) permits reasoning on infinite structures. It is carefully written to that end. Also, the “injection law” (i.e. what you suggest) allows the same nullary instance as the quantification law for IO.
In particular:
data HideIO a
where HideIO :: forall b. IO b -> HideIO a
equipped with the trivial/nullary traversable instance.
toTrav = HideIO
this gives a “lawful” foldable with toList = [], just as with the “quantification law”.
Note that you can’t do this in general (otherwise the law would be useless). In particular, a type
data Hide a
where Hide :: forall b. b -> Hide a
would not give `Hide` as a genuine injection, since we couldn’t actually distinguish the application to different values.
However, because we’re in IO, we can recover a genuine injection, by various means — some more nefarious than others.
The two laws really _are_ saying almost the same things. The quantification in the first version is nearly an extremely-spelled-out version of the injectivity condition.
—Gershom
On May 5, 2018 at 10:18:34 PM, David Feuer (david.feuer at gmail.com) wrote:
My law, unlike yours, also prohibits Foldable IO.
On Sat, May 5, 2018, 6:56 PM David Feuer wrote:
Ah, actually, I think mine *is* stronger, because it can say more about infinite structures.
On Sat, May 5, 2018, 6:46 PM David Feuer wrote:
Okay, I'm not actually sure mine is stronger, but it's definitely easier to understand!
On Sat, May 5, 2018, 6:44 PM Gershom B wrote:
As per: https://wiki.haskell.org/Core_Libraries_Committee emailing libraries@ should suffice. But in the case it doesn’t, I’m now ccing the committee alias directly as well.
The law you suggested does not seem to be generally stronger than mine, but I would be interested in a counterexample if you can produce one[1]. I agree that “strange GADTy instances” are not ruled out, but I’m not sure if I’d consider it a limitation of Foldable, but more a characteristic of GADTs that isn’t per-se wrong, although it sometimes is counterintuitive :-)
Best,
Gershom
[1] If one is to be found, one would think it’d have to do with GADTs. But I think GADTs are flexible enough that one could still provide an injection from a GADT without traversable GADT with traversable such that whatever weird stuff occurs in the former still occurs in the latter.
On May 5, 2018 at 6:23:04 PM, David Feuer (david.feuer at gmail.com) wrote:
You'll have to email the committee if you want them to consider anything. The law I suggested is rather stronger than yours, but I think it's probably closer to what you really meant. Neither option prevents strange GADTy instances, but I suspect that's a fundamental limitation of Foldable.
On Sat, May 5, 2018, 6:13 PM Gershom B wrote:
Hmm… I think this works, and specifies the same law. Nice. Assuming I’m not wrong about that, I’m happy with either version, and will leave it to the committee to decide.
Best,
Gershom
On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com) wrote:
Let me take that back. Injectivity is necessary. And I meant
foldMap @t f = foldMapDefault f . toTrav
On Sat, May 5, 2018, 5:11 PM David Feuer wrote:
Actually, requiring injectivity shouldn't be necessary.
On Sat, May 5, 2018, 5:09 PM David Feuer wrote:
I have another idea that might be worth considering. I think it's a lot simpler than yours.
Law: If t is a Foldable instance, then there must exist:
1. A Traversable instance u and
2. An injective function
toTrav :: t a -> u a
Such that
foldMap @t = foldMapDefault . toTrav
I'm pretty sure this gets at the point you're trying to make.
On May 3, 2018 11:58 AM, "Gershom B" wrote:
This came up before (see the prior thread):
https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
The thread at that time grew rather large, and only at the end did I
come up with what I continue to think is a satisfactory formulation of
the law.
However, at that point nobody really acted to do anything about it.
I would like to _formally request that the core libraries committee
review_ the final version of the law as proposed, for addition to
Foldable documentation:
==
Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
Ord), where GenericSet is otherwise fully abstract:
forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
maybe True (`Foldable.elem` x) (g x) =/= False
==
The intuition is: "there is no general way to get an `a` out of `f a`
which cannot be seen by the `Foldable` instance". The use of
`GenericSet` is to handle the case of GADTs, since even parametric
polymorphic functions on them may at given _already known_ types have
specific behaviors.
This law also works over infinite structures.
It rules out "obviously wrong" instances and accepts all the instances
we want to that I am aware of.
My specific motivation for raising this again is that I am rather
tired of people saying "well, Foldable has no laws, and it is in base,
so things without laws are just fine." Foldable does a have a law we
all know to obey. It just has been rather tricky to state. The above
provides a decent way to state it. So we should state it.
Cheers,
Gershom
_______________________________________________
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 ekmett at gmail.com Sun May 6 02:37:17 2018
From: ekmett at gmail.com (Edward Kmett)
Date: Sat, 5 May 2018 22:37:17 -0400
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
I actually don't have any real objection to something like David's version
of the law.
Unlike the GenericSet version, it at first glance feels like it handles the
GADT-based cases without tripping on the cases where the law doesn't apply
because it doesn't just doesn't type check. That had been my major
objection to Gershom's law.
-Edward
On Sat, May 5, 2018 at 5:09 PM, David Feuer wrote:
> I have another idea that might be worth considering. I think it's a lot
> simpler than yours.
>
> Law: If t is a Foldable instance, then there must exist:
>
> 1. A Traversable instance u and
> 2. An injective function
> toTrav :: t a -> u a
>
> Such that
>
> foldMap @t = foldMapDefault . toTrav
>
> I'm pretty sure this gets at the point you're trying to make.
>
>
> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>
> This came up before (see the prior thread):
> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>
> The thread at that time grew rather large, and only at the end did I
> come up with what I continue to think is a satisfactory formulation of
> the law.
>
> However, at that point nobody really acted to do anything about it.
>
> I would like to _formally request that the core libraries committee
> review_ the final version of the law as proposed, for addition to
> Foldable documentation:
>
> ==
> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
> Ord), where GenericSet is otherwise fully abstract:
>
> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
> maybe True (`Foldable.elem` x) (g x) =/= False
> ==
>
> The intuition is: "there is no general way to get an `a` out of `f a`
> which cannot be seen by the `Foldable` instance". The use of
> `GenericSet` is to handle the case of GADTs, since even parametric
> polymorphic functions on them may at given _already known_ types have
> specific behaviors.
>
> This law also works over infinite structures.
>
> It rules out "obviously wrong" instances and accepts all the instances
> we want to that I am aware of.
>
> My specific motivation for raising this again is that I am rather
> tired of people saying "well, Foldable has no laws, and it is in base,
> so things without laws are just fine." Foldable does a have a law we
> all know to obey. It just has been rather tricky to state. The above
> provides a decent way to state it. So we should state it.
>
> Cheers,
> Gershom
> _______________________________________________
> 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 Sun May 6 02:43:33 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 06 May 2018 02:43:33 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
HideIO is devious, but I'd argue it's not a proper injection. In particular,
HideIO (fmap g m) is indistinguishable from HideIO m, even if fmap g m is
distinguishable from m.
Your law doesn't blow up for infinite structures (your care wasn't for
nothing) but it doesn't say very much about them.
On Sat, May 5, 2018, 10:37 PM Gershom B wrote:
> I think you’re wrong on both counts. The “quantification law” (i.e. what i
> suggest) permits reasoning on infinite structures. It is carefully written
> to that end. Also, the “injection law” (i.e. what you suggest) allows the
> same nullary instance as the quantification law for IO.
>
> In particular:
>
> data HideIO a
> where HideIO :: forall b. IO b -> HideIO a
>
> equipped with the trivial/nullary traversable instance.
>
> toTrav = HideIO
>
> this gives a “lawful” foldable with toList = [], just as with the
> “quantification law”.
>
> Note that you can’t do this in general (otherwise the law would be
> useless). In particular, a type
>
> data Hide a
> where Hide :: forall b. b -> Hide a
>
> would not give `Hide` as a genuine injection, since we couldn’t actually
> distinguish the application to different values.
>
> However, because we’re in IO, we can recover a genuine injection, by
> various means — some more nefarious than others.
>
> The two laws really _are_ saying almost the same things. The
> quantification in the first version is nearly an extremely-spelled-out
> version of the injectivity condition.
>
> —Gershom
>
>
> On May 5, 2018 at 10:18:34 PM, David Feuer (david.feuer at gmail.com) wrote:
>
> My law, unlike yours, also prohibits Foldable IO.
>
> On Sat, May 5, 2018, 6:56 PM David Feuer wrote:
>
>> Ah, actually, I think mine *is* stronger, because it can say more about
>> infinite structures.
>>
>> On Sat, May 5, 2018, 6:46 PM David Feuer wrote:
>>
>>> Okay, I'm not actually sure mine is stronger, but it's definitely easier
>>> to understand!
>>>
>>> On Sat, May 5, 2018, 6:44 PM Gershom B wrote:
>>>
>>>> As per: https://wiki.haskell.org/Core_Libraries_Committee emailing
>>>> libraries@ should suffice. But in the case it doesn’t, I’m now ccing
>>>> the committee alias directly as well.
>>>>
>>>> The law you suggested does not seem to be generally stronger than mine,
>>>> but I would be interested in a counterexample if you can produce one[1]. I
>>>> agree that “strange GADTy instances” are not ruled out, but I’m not sure if
>>>> I’d consider it a limitation of Foldable, but more a characteristic of
>>>> GADTs that isn’t per-se wrong, although it sometimes is counterintuitive :-)
>>>>
>>>> Best,
>>>> Gershom
>>>>
>>>> [1] If one is to be found, one would think it’d have to do with GADTs.
>>>> But I think GADTs are flexible enough that one could still provide an
>>>> injection from a GADT without traversable GADT with traversable such that
>>>> whatever weird stuff occurs in the former still occurs in the latter.
>>>>
>>>> On May 5, 2018 at 6:23:04 PM, David Feuer (david.feuer at gmail.com)
>>>> wrote:
>>>>
>>>> You'll have to email the committee if you want them to consider
>>>> anything. The law I suggested is rather stronger than yours, but I think
>>>> it's probably closer to what you really meant. Neither option prevents
>>>> strange GADTy instances, but I suspect that's a fundamental limitation of
>>>> Foldable.
>>>>
>>>> On Sat, May 5, 2018, 6:13 PM Gershom B wrote:
>>>>
>>>>> Hmm… I think this works, and specifies the same law. Nice. Assuming
>>>>> I’m not wrong about that, I’m happy with either version, and will leave it
>>>>> to the committee to decide.
>>>>>
>>>>> Best,
>>>>> Gershom
>>>>>
>>>>> On May 5, 2018 at 5:18:29 PM, David Feuer (david.feuer at gmail.com)
>>>>> wrote:
>>>>>
>>>>> Let me take that back. Injectivity is necessary. And I meant
>>>>>
>>>>> foldMap @t f = foldMapDefault f . toTrav
>>>>>
>>>>> On Sat, May 5, 2018, 5:11 PM David Feuer
>>>>> wrote:
>>>>>
>>>>>> Actually, requiring injectivity shouldn't be necessary.
>>>>>>
>>>>>> On Sat, May 5, 2018, 5:09 PM David Feuer
>>>>>> wrote:
>>>>>>
>>>>>>> I have another idea that might be worth considering. I think it's a
>>>>>>> lot simpler than yours.
>>>>>>>
>>>>>>> Law: If t is a Foldable instance, then there must exist:
>>>>>>>
>>>>>>> 1. A Traversable instance u and
>>>>>>> 2. An injective function
>>>>>>> toTrav :: t a -> u a
>>>>>>>
>>>>>>> Such that
>>>>>>>
>>>>>>> foldMap @t = foldMapDefault . toTrav
>>>>>>>
>>>>>>> I'm pretty sure this gets at the point you're trying to make.
>>>>>>>
>>>>>>>
>>>>>>> On May 3, 2018 11:58 AM, "Gershom B" wrote:
>>>>>>>
>>>>>>> This came up before (see the prior thread):
>>>>>>>
>>>>>>> https://mail.haskell.org/pipermail/libraries/2015-February/024943.html
>>>>>>>
>>>>>>> The thread at that time grew rather large, and only at the end did I
>>>>>>> come up with what I continue to think is a satisfactory formulation
>>>>>>> of
>>>>>>> the law.
>>>>>>>
>>>>>>> However, at that point nobody really acted to do anything about it.
>>>>>>>
>>>>>>> I would like to _formally request that the core libraries committee
>>>>>>> review_ the final version of the law as proposed, for addition to
>>>>>>> Foldable documentation:
>>>>>>>
>>>>>>> ==
>>>>>>> Given a fresh newtype GenericSet = GenericSet Integer deriving (Eq,
>>>>>>> Ord), where GenericSet is otherwise fully abstract:
>>>>>>>
>>>>>>> forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet).
>>>>>>> maybe True (`Foldable.elem` x) (g x) =/= False
>>>>>>> ==
>>>>>>>
>>>>>>> The intuition is: "there is no general way to get an `a` out of `f a`
>>>>>>> which cannot be seen by the `Foldable` instance". The use of
>>>>>>> `GenericSet` is to handle the case of GADTs, since even parametric
>>>>>>> polymorphic functions on them may at given _already known_ types have
>>>>>>> specific behaviors.
>>>>>>>
>>>>>>> This law also works over infinite structures.
>>>>>>>
>>>>>>> It rules out "obviously wrong" instances and accepts all the
>>>>>>> instances
>>>>>>> we want to that I am aware of.
>>>>>>>
>>>>>>> My specific motivation for raising this again is that I am rather
>>>>>>> tired of people saying "well, Foldable has no laws, and it is in
>>>>>>> base,
>>>>>>> so things without laws are just fine." Foldable does a have a law we
>>>>>>> all know to obey. It just has been rather tricky to state. The above
>>>>>>> provides a decent way to state it. So we should state it.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Gershom
>>>>>>> _______________________________________________
>>>>>>> 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 gershomb at gmail.com Sun May 6 03:17:42 2018
From: gershomb at gmail.com (Gershom B)
Date: Sat, 5 May 2018 23:17:42 -0400
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID:
On May 5, 2018 at 10:43:57 PM, David Feuer (david.feuer at gmail.com) wrote:
Your law doesn't blow up for infinite structures (your care wasn't for nothing) but it doesn't say very much about them.
No, I’m pretty sure that the two formulations say exactly the same thing in this case. I do think that your formulation is more elegant and if that helps the committee along to a decision, as I said, I’m more than happy if they go with it. I just want to be sufficiently clear on what is being said by either formulation. And if you do have a good example where they differ on infinite structures, it would be interesting to see.
-g
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From david.feuer at gmail.com Sun May 6 03:27:16 2018
From: david.feuer at gmail.com (David Feuer)
Date: Sun, 06 May 2018 03:27:16 +0000
Subject: Proposal: add a foldable law
In-Reply-To:
References:
Message-ID: