Deprecate Foldable for Either

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
76 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Deprecate Foldable for Either

Andreas Abel
Today a student came to me wondering why a certain function produced a
regular result, where he had expected an error.  Turned out he had used
`concat`, but not on a lists of lists as he had thought, but on a lists
of `Either a [b]`.

With the Foldable instance for Either, which considers Either a b to be
a container of 0-1 elements of b, errors are happily swallowed.

I think this instance is harmful and should be deprecated (and later
removed) from base.

There are similarly pointless Foldable instances as well.

See a discussion one year ago, which was heated, but had no consequences.

https://mail.haskell.org/pipermail/libraries/2016-February/026678.html


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Henning Thielemann

On Thu, 2 Mar 2017, Andreas Abel wrote:

> Today a student came to me wondering why a certain function produced a
> regular result, where he had expected an error.  Turned out he had used
> `concat`, but not on a lists of lists as he had thought, but on a lists
> of `Either a [b]`.

That is, he did (concat (xs :: [Either a [b]]))? Does GHC actually accept
that? If at all, it would not have to do with Foldable.
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

David Feuer
In reply to this post by Andreas Abel
The problem is that we'd then lose the perfectly good Traversable instance, which would be sad.

On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]> wrote:
Today a student came to me wondering why a certain function produced a regular result, where he had expected an error.  Turned out he had used `concat`, but not on a lists of lists as he had thought, but on a lists of `Either a [b]`.

With the Foldable instance for Either, which considers Either a b to be a container of 0-1 elements of b, errors are happily swallowed.

I think this instance is harmful and should be deprecated (and later removed) from base.

There are similarly pointless Foldable instances as well.

See a discussion one year ago, which was heated, but had no consequences.

https://mail.haskell.org/pipermail/libraries/2016-February/026678.html


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Matthew Pickering
Another type can be added to base which does have the Traversable instance.

On Thu, Mar 2, 2017 at 4:48 PM, David Feuer <[hidden email]> wrote:

> The problem is that we'd then lose the perfectly good Traversable instance,
> which would be sad.
>
> On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]> wrote:
>>
>> Today a student came to me wondering why a certain function produced a
>> regular result, where he had expected an error.  Turned out he had used
>> `concat`, but not on a lists of lists as he had thought, but on a lists of
>> `Either a [b]`.
>>
>> With the Foldable instance for Either, which considers Either a b to be a
>> container of 0-1 elements of b, errors are happily swallowed.
>>
>> I think this instance is harmful and should be deprecated (and later
>> removed) from base.
>>
>> There are similarly pointless Foldable instances as well.
>>
>> See a discussion one year ago, which was heated, but had no consequences.
>>
>> https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
>>
>>
>> --
>> Andreas Abel  <><      Du bist der geliebte Mensch.
>>
>> Department of Computer Science and Engineering
>> Chalmers and Gothenburg University, Sweden
>>
>> [hidden email]
>> http://www.cse.chalmers.se/~abela/
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Francesco Ariis
In reply to this post by Andreas Abel
On Thu, Mar 02, 2017 at 05:22:48PM +0100, Andreas Abel wrote:
> Today a student came to me wondering why a certain function produced a
> regular result, where he had expected an error.  Turned out he had used
> `concat`, but not on a lists of lists as he had thought, but on a lists of
> `Either a [b]`.

I keep making the same mistake when using Parsec to process a file;
calling `length` on the result (to check how many thingies I have
parsed) returns 1, 1 and again 1, no matter how many times I tinker
with the code.
I feel such a fool after recognising my misstep, every time.

> With the Foldable instance for Either, which considers Either a b to be a
> container of 0-1 elements of b, errors are happily swallowed.
>
> I think this instance is harmful and should be deprecated (and later
> removed) from base.
>
> There are similarly pointless Foldable instances as well.
>
> See a discussion one year ago, which was heated, but had no consequences.

I suspect it had no consequences because the mother of all battles was
"Foldable and Traversable to become importable unqualified"; and once
you set the goal (and reap the benefits: Traversable), you have to live
with some of the annoying consequences.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Andreas Abel
In reply to this post by David Feuer
Ok, Foldable is a formal condition for Traversable, but not actually
used in the implementation of Traversable Either.  This still leaves
room to implement Foldable for Either by

   instance Foldable (Either a) where
     foldMap _ _ = error "Folding Either?  Naah, I don't think this is a
good idea."

On 02.03.2017 17:48, David Feuer wrote:

> The problem is that we'd then lose the perfectly good Traversable
> instance, which would be sad.
>
> On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Today a student came to me wondering why a certain function produced
>     a regular result, where he had expected an error.  Turned out he had
>     used `concat`, but not on a lists of lists as he had thought, but on
>     a lists of `Either a [b]`.
>
>     With the Foldable instance for Either, which considers Either a b to
>     be a container of 0-1 elements of b, errors are happily swallowed.
>
>     I think this instance is harmful and should be deprecated (and later
>     removed) from base.
>
>     There are similarly pointless Foldable instances as well.
>
>     See a discussion one year ago, which was heated, but had no
>     consequences.
>
>     https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
>     <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>
>
>
>     --
>     Andreas Abel  <><      Du bist der geliebte Mensch.
>
>     Department of Computer Science and Engineering
>     Chalmers and Gothenburg University, Sweden
>
>     [hidden email] <mailto:[hidden email]>
>     http://www.cse.chalmers.se/~abela/ <http://www.cse.chalmers.se/~abela/>
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     <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

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Francesco Ariis
On Thu, Mar 02, 2017 at 05:59:18PM +0100, Andreas Abel wrote:
> Ok, Foldable is a formal condition for Traversable, but not actually used in
> the implementation of Traversable Either.  This still leaves room to
> implement Foldable for Either by
>
>   instance Foldable (Either a) where
>     foldMap _ _ = error "Folding Either?  Naah, I don't think this is a good
> idea."

I don't fancy Foldable for Either either, but runtime failures are
ugly too.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Oliver Charles-3
Personally, I think it would be a shame to lose foldMap on EIther. I frequently foldMap over Maybe values (where mempty is suitable in case of "failure"), and I can certainly see myself doing the same thing with Either.

- ocharles

On Thu, Mar 2, 2017 at 5:08 PM Francesco Ariis <[hidden email]> wrote:
On Thu, Mar 02, 2017 at 05:59:18PM +0100, Andreas Abel wrote:
> Ok, Foldable is a formal condition for Traversable, but not actually used in
> the implementation of Traversable Either.  This still leaves room to
> implement Foldable for Either by
>
>   instance Foldable (Either a) where
>     foldMap _ _ = error "Folding Either?  Naah, I don't think this is a good
> idea."

I don't fancy Foldable for Either either, but runtime failures are
ugly too.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Francesco Ariis
On Thu, Mar 02, 2017 at 05:19:26PM +0000, Oliver Charles wrote:
> Personally, I think it would be a shame to lose foldMap on EIther. I
> frequently foldMap over Maybe values (where mempty is suitable in case of
> "failure"), and I can certainly see myself doing the same thing with Either.

I am not trying to be polemic, just to see where the community
stands: regarding Either/Maybe: do you have use cases for length
(sum) too?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Kris Nuttycombe
As with all of these discussions, the point of having Either be Foldable is not that you're going to call foldMap on an Either value directly. Instead, it is that you be able to pass whatever sort of foldable thing you choose (which Either certainly is) to a function that only requires foldability of its input. By removing or damaging the Foldable instance for Either, you don't simply prevent people from encountering problems that will be resolved the first time they test their software - you make a whole universe of nicely polymorphic functions unavailable for them to use without additional effort.

In particular, the idea that one should make all such functions partial by throwing an error is repugnant.

Kris

On Thu, Mar 2, 2017 at 10:35 AM, Francesco Ariis <[hidden email]> wrote:
On Thu, Mar 02, 2017 at 05:19:26PM +0000, Oliver Charles wrote:
> Personally, I think it would be a shame to lose foldMap on EIther. I
> frequently foldMap over Maybe values (where mempty is suitable in case of
> "failure"), and I can certainly see myself doing the same thing with Either.

I am not trying to be polemic, just to see where the community
stands: regarding Either/Maybe: do you have use cases for length
(sum) too?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Dan Burton
Of course errors are swallowed. Look at the type signature.

concat :: Foldable t => t [b] -> [b]
-- t = Either a
concat :: Either a [b] -> [b]

The error type "a" does not appear anywhere in the function's output type. In the event of an error, the only thing it could possibly produce as output is an empty list.

I don't think this means that Either's foldable instance is harmful and should be removed. It's a perfectly good instance that behaves in the "obvious" Maybe-like way. I do think this is an argument in favor of using a custom Prelude (which uses functions specialized to lists) when teaching new students.

Any Traversable instance should absolutely be Foldable, with foldMap = foldMapDefault, or an optimized version that produces the same result. Putting `foldMap = error ...` for any Traversable is out of the question, imo.

-- Dan Burton

On Thu, Mar 2, 2017 at 10:12 AM, Kris Nuttycombe <[hidden email]> wrote:
As with all of these discussions, the point of having Either be Foldable is not that you're going to call foldMap on an Either value directly. Instead, it is that you be able to pass whatever sort of foldable thing you choose (which Either certainly is) to a function that only requires foldability of its input. By removing or damaging the Foldable instance for Either, you don't simply prevent people from encountering problems that will be resolved the first time they test their software - you make a whole universe of nicely polymorphic functions unavailable for them to use without additional effort.

In particular, the idea that one should make all such functions partial by throwing an error is repugnant.

Kris

On Thu, Mar 2, 2017 at 10:35 AM, Francesco Ariis <[hidden email]> wrote:
On Thu, Mar 02, 2017 at 05:19:26PM +0000, Oliver Charles wrote:
> Personally, I think it would be a shame to lose foldMap on EIther. I
> frequently foldMap over Maybe values (where mempty is suitable in case of
> "failure"), and I can certainly see myself doing the same thing with Either.

I am not trying to be polemic, just to see where the community
stands: regarding Either/Maybe: do you have use cases for length
(sum) too?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Andreas Abel
In reply to this post by Kris Nuttycombe
 > a whole universe of nicely polymorphic functions unavailable for them to
 > use without additional effort.

At least in terms of Either, I do not see a "universe of nicely
polymorphic functions" here.  I'd say applying a Foldable on a complex
data structure build of all sorts of type constructors that involve
Either (and tuples) is highly counterintuitive.

For a start, the "sums-of-products" representation of data types is not
stable under our Foldable instances.

   data D a
     = C1 a
     | C2 a a
     deriving (Foldable)

gives you a completely different Foldable instance than its
sums-of-product representation

   Either a (a, a)

Andreas

On 02.03.2017 19:12, Kris Nuttycombe wrote:

> As with all of these discussions, the point of having Either be Foldable
> is not that you're going to call foldMap on an Either value directly.
> Instead, it is that you be able to pass whatever sort of foldable thing
> you choose (which Either certainly is) to a function that only requires
> foldability of its input. By removing or damaging the Foldable instance
> for Either, you don't simply prevent people from encountering problems
> that will be resolved the first time they test their software - you make
> a whole universe of nicely polymorphic functions unavailable for them to
> use without additional effort.
>
> In particular, the idea that one should make all such functions partial
> by throwing an error is repugnant.
>
> Kris
>
> On Thu, Mar 2, 2017 at 10:35 AM, Francesco Ariis <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Thu, Mar 02, 2017 at 05:19:26PM +0000, Oliver Charles wrote:
>     > Personally, I think it would be a shame to lose foldMap on EIther. I
>     > frequently foldMap over Maybe values (where mempty is suitable in case of
>     > "failure"), and I can certainly see myself doing the same thing with Either.
>
>     I am not trying to be polemic, just to see where the community
>     stands: regarding Either/Maybe: do you have use cases for length
>     (sum) too?
>
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> 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

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

David Feuer
In reply to this post by Dan Burton
foldMapDefault and fmapDefault *should* actually perform quite well, by the way, unless the specialized definitions come with rewrite rules.

On Mar 2, 2017 1:50 PM, "Dan Burton" <[hidden email]> wrote:
Of course errors are swallowed. Look at the type signature.

concat :: Foldable t => t [b] -> [b]
-- t = Either a
concat :: Either a [b] -> [b]

The error type "a" does not appear anywhere in the function's output type. In the event of an error, the only thing it could possibly produce as output is an empty list.

I don't think this means that Either's foldable instance is harmful and should be removed. It's a perfectly good instance that behaves in the "obvious" Maybe-like way. I do think this is an argument in favor of using a custom Prelude (which uses functions specialized to lists) when teaching new students.

Any Traversable instance should absolutely be Foldable, with foldMap = foldMapDefault, or an optimized version that produces the same result. Putting `foldMap = error ...` for any Traversable is out of the question, imo.

-- Dan Burton

On Thu, Mar 2, 2017 at 10:12 AM, Kris Nuttycombe <[hidden email]> wrote:
As with all of these discussions, the point of having Either be Foldable is not that you're going to call foldMap on an Either value directly. Instead, it is that you be able to pass whatever sort of foldable thing you choose (which Either certainly is) to a function that only requires foldability of its input. By removing or damaging the Foldable instance for Either, you don't simply prevent people from encountering problems that will be resolved the first time they test their software - you make a whole universe of nicely polymorphic functions unavailable for them to use without additional effort.

In particular, the idea that one should make all such functions partial by throwing an error is repugnant.

Kris

On Thu, Mar 2, 2017 at 10:35 AM, Francesco Ariis <[hidden email]> wrote:
On Thu, Mar 02, 2017 at 05:19:26PM +0000, Oliver Charles wrote:
> Personally, I think it would be a shame to lose foldMap on EIther. I
> frequently foldMap over Maybe values (where mempty is suitable in case of
> "failure"), and I can certainly see myself doing the same thing with Either.

I am not trying to be polemic, just to see where the community
stands: regarding Either/Maybe: do you have use cases for length
(sum) too?

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Edward Kmett-2
In reply to this post by Andreas Abel
I'm very strongly -1 against deprecating or removing this instance. 

It removes an instance that is the only possible instance for the type for purely proscriptive reasons. The moment someone needs it they now have to make a new data type with completely identical instances for everything else, but this actively gets in the way of code sharing and reuse.

On top of that, using mapM over Either or Maybe is a fairly common idiom today, so the implications would be wide-reaching.

-Edward

On Thu, Mar 2, 2017 at 11:22 AM, Andreas Abel <[hidden email]> wrote:
Today a student came to me wondering why a certain function produced a regular result, where he had expected an error.  Turned out he had used `concat`, but not on a lists of lists as he had thought, but on a lists of `Either a [b]`.

With the Foldable instance for Either, which considers Either a b to be a container of 0-1 elements of b, errors are happily swallowed.

I think this instance is harmful and should be deprecated (and later removed) from base.

There are similarly pointless Foldable instances as well.

See a discussion one year ago, which was heated, but had no consequences.

https://mail.haskell.org/pipermail/libraries/2016-February/026678.html


--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Edward Kmett-2
In reply to this post by Andreas Abel

On Thu, Mar 2, 2017 at 11:59 AM, Andreas Abel <[hidden email]> wrote:
Ok, Foldable is a formal condition for Traversable, but not actually used in the implementation of Traversable Either.  This still leaves room to implement Foldable for Either by

  instance Foldable (Either a) where
    foldMap _ _ = error "Folding Either?  Naah, I don't think this is a good idea."


This would change the semantic of every

forM_ myeither $ \i -> .... 

in existing code to silent errors.

Hell no.

-Edward
 
On 02.03.2017 17:48, David Feuer wrote:
The problem is that we'd then lose the perfectly good Traversable
instance, which would be sad.

On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]
<mailto:[hidden email]>> wrote:

    Today a student came to me wondering why a certain function produced
    a regular result, where he had expected an error.  Turned out he had
    used `concat`, but not on a lists of lists as he had thought, but on
    a lists of `Either a [b]`.

    With the Foldable instance for Either, which considers Either a b to
    be a container of 0-1 elements of b, errors are happily swallowed.

    I think this instance is harmful and should be deprecated (and later
    removed) from base.

    There are similarly pointless Foldable instances as well.

    See a discussion one year ago, which was heated, but had no
    consequences.

    https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
    <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>


    --
    Andreas Abel  <><      Du bist der geliebte Mensch.

    Department of Computer Science and Engineering
    Chalmers and Gothenburg University, Sweden

    [hidden email] <mailto:[hidden email]>
    http://www.cse.chalmers.se/~abela/ <http://www.cse.chalmers.se/~abela/>
    _______________________________________________
    Libraries mailing list
    [hidden email] <mailto:[hidden email]>
    http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
    <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

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Andreas Abel
We could have a module

   Data.List.ReallyJustListsAndNotSomeThingMoreGeneric

which implements concat and friends just for lists and could be imported
if one wants to have the list operations.  Currently,

   import qualified Data.List as List

does not give on the list operations as e.g.

   List.concat

but the generic ones.

See also http://ghc.haskell.org/trac/ghc/ticket/13345

On 02.03.2017 20:02, Edward Kmett wrote:

>
> On Thu, Mar 2, 2017 at 11:59 AM, Andreas Abel <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Ok, Foldable is a formal condition for Traversable, but not actually
>     used in the implementation of Traversable Either.  This still leaves
>     room to implement Foldable for Either by
>
>       instance Foldable (Either a) where
>         foldMap _ _ = error "Folding Either?  Naah, I don't think this
>     is a good idea."
>
>
> This would change the semantic of every
>
> forM_ myeither $ \i -> ....
>
> in existing code to silent errors.
>
> Hell no.
>
> -Edward
>
>
>     On 02.03.2017 17:48, David Feuer wrote:
>
>         The problem is that we'd then lose the perfectly good Traversable
>         instance, which would be sad.
>
>         On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>             Today a student came to me wondering why a certain function
>         produced
>             a regular result, where he had expected an error.  Turned
>         out he had
>             used `concat`, but not on a lists of lists as he had
>         thought, but on
>             a lists of `Either a [b]`.
>
>             With the Foldable instance for Either, which considers
>         Either a b to
>             be a container of 0-1 elements of b, errors are happily
>         swallowed.
>
>             I think this instance is harmful and should be deprecated
>         (and later
>             removed) from base.
>
>             There are similarly pointless Foldable instances as well.
>
>             See a discussion one year ago, which was heated, but had no
>             consequences.
>
>
>         https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
>         <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>
>
>         <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
>         <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>>
>
>
>             --
>             Andreas Abel  <><      Du bist der geliebte Mensch.
>
>             Department of Computer Science and Engineering
>             Chalmers and Gothenburg University, Sweden
>
>             [hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>             http://www.cse.chalmers.se/~abela/
>         <http://www.cse.chalmers.se/~abela/>
>         <http://www.cse.chalmers.se/~abela/
>         <http://www.cse.chalmers.se/~abela/>>
>             _______________________________________________
>             Libraries mailing list
>             [hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>
>             http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
>             <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>         <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
>
>     [hidden email] <mailto:[hidden email]>
>     http://www.cse.chalmers.se/~abela/ <http://www.cse.chalmers.se/~abela/>
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>     <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

[hidden email]
http://www.cse.chalmers.se/~abela/
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

David Feuer
Yes. That is an excellent plan. I'd love to call it Data.List, but others will disagree.

On Mar 2, 2017 2:17 PM, "Andreas Abel" <[hidden email]> wrote:
We could have a module

  Data.List.ReallyJustListsAndNotSomeThingMoreGeneric

which implements concat and friends just for lists and could be imported if one wants to have the list operations.  Currently,

  import qualified Data.List as List

does not give on the list operations as e.g.

  List.concat

but the generic ones.

See also http://ghc.haskell.org/trac/ghc/ticket/13345

On 02.03.2017 20:02, Edward Kmett wrote:

On Thu, Mar 2, 2017 at 11:59 AM, Andreas Abel <[hidden email]
<mailto:[hidden email]>> wrote:

    Ok, Foldable is a formal condition for Traversable, but not actually
    used in the implementation of Traversable Either.  This still leaves
    room to implement Foldable for Either by

      instance Foldable (Either a) where
        foldMap _ _ = error "Folding Either?  Naah, I don't think this
    is a good idea."


This would change the semantic of every

forM_ myeither $ \i -> ....

in existing code to silent errors.

Hell no.

-Edward


    On 02.03.2017 17:48, David Feuer wrote:

        The problem is that we'd then lose the perfectly good Traversable
        instance, which would be sad.

        On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]
        <mailto:[hidden email]>
        <mailto:[hidden email]
        <mailto:[hidden email]>>> wrote:

            Today a student came to me wondering why a certain function
        produced
            a regular result, where he had expected an error.  Turned
        out he had
            used `concat`, but not on a lists of lists as he had
        thought, but on
            a lists of `Either a [b]`.

            With the Foldable instance for Either, which considers
        Either a b to
            be a container of 0-1 elements of b, errors are happily
        swallowed.

            I think this instance is harmful and should be deprecated
        (and later
            removed) from base.

            There are similarly pointless Foldable instances as well.

            See a discussion one year ago, which was heated, but had no
            consequences.


        https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>

        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>>


            --
            Andreas Abel  <><      Du bist der geliebte Mensch.

            Department of Computer Science and Engineering
            Chalmers and Gothenburg University, Sweden

            [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
            http://www.cse.chalmers.se/~abela/
        <http://www.cse.chalmers.se/~abela/>
        <http://www.cse.chalmers.se/~abela/
        <http://www.cse.chalmers.se/~abela/>>
            _______________________________________________
            Libraries mailing list
            [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
            http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
        <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
            <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
        <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

    [hidden email] <mailto:[hidden email]>
    http://www.cse.chalmers.se/~abela/ <http://www.cse.chalmers.se/~abela/>
    _______________________________________________
    Libraries mailing list
    [hidden email] <mailto:[hidden email]>
    http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
    <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

[hidden email]
http://www.cse.chalmers.se/~abela/

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Edward Kmett-2
In reply to this post by Andreas Abel
The nice thing about such a module is anybody can package it up. It needs nothing special from base. During the discussion about Foldable, the option to add a Data.List.Explicit or something that contained just the monomorphic variants was brought up as something we could add, but nobody really got enthusiastic over the idea.

The state of Data.List today is a messy intermediate state:


When and if we get a resolution to https://ghc.haskell.org/trac/ghc/ticket/4879 we're likely to proceed with option 1 from that FTP page, which will at least avoid Data.List.concat having the too general type, by dint of it no longer existing.

-Edward

On Thu, Mar 2, 2017 at 2:17 PM, Andreas Abel <[hidden email]> wrote:
We could have a module

  Data.List.ReallyJustListsAndNotSomeThingMoreGeneric

which implements concat and friends just for lists and could be imported if one wants to have the list operations.  Currently,

  import qualified Data.List as List

does not give on the list operations as e.g.

  List.concat

but the generic ones.

See also http://ghc.haskell.org/trac/ghc/ticket/13345

On 02.03.2017 20:02, Edward Kmett wrote:

On Thu, Mar 2, 2017 at 11:59 AM, Andreas Abel <[hidden email]
<mailto:[hidden email]>> wrote:

    Ok, Foldable is a formal condition for Traversable, but not actually
    used in the implementation of Traversable Either.  This still leaves
    room to implement Foldable for Either by

      instance Foldable (Either a) where
        foldMap _ _ = error "Folding Either?  Naah, I don't think this
    is a good idea."


This would change the semantic of every

forM_ myeither $ \i -> ....

in existing code to silent errors.

Hell no.

-Edward


    On 02.03.2017 17:48, David Feuer wrote:

        The problem is that we'd then lose the perfectly good Traversable
        instance, which would be sad.

        On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]
        <mailto:[hidden email]>
        <mailto:[hidden email]

        <mailto:[hidden email]>>> wrote:

            Today a student came to me wondering why a certain function
        produced
            a regular result, where he had expected an error.  Turned
        out he had
            used `concat`, but not on a lists of lists as he had
        thought, but on
            a lists of `Either a [b]`.

            With the Foldable instance for Either, which considers
        Either a b to
            be a container of 0-1 elements of b, errors are happily
        swallowed.

            I think this instance is harmful and should be deprecated
        (and later
            removed) from base.

            There are similarly pointless Foldable instances as well.

            See a discussion one year ago, which was heated, but had no
            consequences.


        https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>

        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>>


            --
            Andreas Abel  <><      Du bist der geliebte Mensch.

            Department of Computer Science and Engineering
            Chalmers and Gothenburg University, Sweden

            [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
            http://www.cse.chalmers.se/~abela/
        <http://www.cse.chalmers.se/~abela/>
        <http://www.cse.chalmers.se/~abela/
        <http://www.cse.chalmers.se/~abela/>>
            _______________________________________________
            Libraries mailing list
            [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
            http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
        <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
            <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
        <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

    [hidden email] <mailto:[hidden email]>
    http://www.cse.chalmers.se/~abela/ <http://www.cse.chalmers.se/~abela/>
    _______________________________________________
    Libraries mailing list
    [hidden email] <mailto:[hidden email]>
    http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
    <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

[hidden email]
http://www.cse.chalmers.se/~abela/


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Edward Kmett-2
In reply to this post by David Feuer
Sadly, doing so in Data.List would lead to massive breakage as Data.List is specified by the report and is very, very widely imported unqualified just to get at things like sort.

-Edward

On Thu, Mar 2, 2017 at 2:28 PM, David Feuer <[hidden email]> wrote:
Yes. That is an excellent plan. I'd love to call it Data.List, but others will disagree.

On Mar 2, 2017 2:17 PM, "Andreas Abel" <[hidden email]> wrote:
We could have a module

  Data.List.ReallyJustListsAndNotSomeThingMoreGeneric

which implements concat and friends just for lists and could be imported if one wants to have the list operations.  Currently,

  import qualified Data.List as List

does not give on the list operations as e.g.

  List.concat

but the generic ones.

See also http://ghc.haskell.org/trac/ghc/ticket/13345

On 02.03.2017 20:02, Edward Kmett wrote:

On Thu, Mar 2, 2017 at 11:59 AM, Andreas Abel <[hidden email]
<mailto:[hidden email]>> wrote:

    Ok, Foldable is a formal condition for Traversable, but not actually
    used in the implementation of Traversable Either.  This still leaves
    room to implement Foldable for Either by

      instance Foldable (Either a) where
        foldMap _ _ = error "Folding Either?  Naah, I don't think this
    is a good idea."


This would change the semantic of every

forM_ myeither $ \i -> ....

in existing code to silent errors.

Hell no.

-Edward


    On 02.03.2017 17:48, David Feuer wrote:

        The problem is that we'd then lose the perfectly good Traversable
        instance, which would be sad.

        On Mar 2, 2017 11:23 AM, "Andreas Abel" <[hidden email]
        <mailto:[hidden email]>
        <mailto:[hidden email]
        <mailto:[hidden email]>>> wrote:

            Today a student came to me wondering why a certain function
        produced
            a regular result, where he had expected an error.  Turned
        out he had
            used `concat`, but not on a lists of lists as he had
        thought, but on
            a lists of `Either a [b]`.

            With the Foldable instance for Either, which considers
        Either a b to
            be a container of 0-1 elements of b, errors are happily
        swallowed.

            I think this instance is harmful and should be deprecated
        (and later
            removed) from base.

            There are similarly pointless Foldable instances as well.

            See a discussion one year ago, which was heated, but had no
            consequences.


        https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>

        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html
        <https://mail.haskell.org/pipermail/libraries/2016-February/026678.html>>


            --
            Andreas Abel  <><      Du bist der geliebte Mensch.

            Department of Computer Science and Engineering
            Chalmers and Gothenburg University, Sweden

            [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
            http://www.cse.chalmers.se/~abela/
        <http://www.cse.chalmers.se/~abela/>
        <http://www.cse.chalmers.se/~abela/
        <http://www.cse.chalmers.se/~abela/>>
            _______________________________________________
            Libraries mailing list
            [hidden email] <mailto:[hidden email]>
        <mailto:[hidden email] <mailto:[hidden email]>>
            http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
        <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries>
            <http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
        <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

    [hidden email] <mailto:[hidden email]>
    http://www.cse.chalmers.se/~abela/ <http://www.cse.chalmers.se/~abela/>
    _______________________________________________
    Libraries mailing list
    [hidden email] <mailto:[hidden email]>
    http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
    <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

[hidden email]
http://www.cse.chalmers.se/~abela/


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Deprecate Foldable for Either

Henrik Nilsson-2
In reply to this post by Kris Nuttycombe
Hi,

Francesco Ariis wrote:

 > I am not trying to be polemic, just to see where the community
 > stands:

Well, personally, I would not miss neither Foldable nor Traversable
instances of (Either b) or ((,) b) for even a fraction of a second.

And I know many people who fully agrees.

Henning summed it up very well, I think:

https://mail.haskell.org/pipermail/libraries/2016-February/026678.html

I am completely and utterly unconvinced by arguments along the lines
that just because one of the standard types *can* be seen as a container
type it must be seen that way, by everyone, no exceptions. That was
never the intent of these types, as evidenced by their names and as
evidenced by the inherent asymmetry of their instances. Pretending
otherwise just creates confusion, of which there are plenty of
instances, with more coming as per Andreas' initial mail. Further
this generality buys very little if anything in practice as anyone
who really needs the functionality can define their own instances or,
better, introduce a custom type with a well-chosen name that clearly
reflects the application in question.

So, indeed, "all consistent but consistently useless", as Henning
eloquently put it. To be concrete: after all, why would I write,
for an x of type Either Int, say,

foldl (+) 0 x

and not simply

either (const 0) id x

?

I know what I find more readable, at least, and I'd be willing
to bet on what is more maintainable as well as time passes and
code is passed from one group of maintainers to another.

Yes, I did see:

Kris Nuttycombe wrote:

 > As with all of these discussions, the point of having Either be
 > Foldable is not that you're going to call foldMap on an Either value
 > directly.

But I must say that strikes me as supremely odd: why on Earth should
one *not* make direct use of instance methods if they make so much sense
as is claimed?

Well, I don't really expect any changes. This is just to say that there
still are lots of people who find the push to instantiate Foldable and
Traversable as widely as possible very unfortunate.

Best,

/Henrik




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
1234