[Haskell-cafe] Foldable for (,)

Matt parsonsmatt at gmail.com
Thu May 4 21:42:11 UTC 2017


Another factor: Foldable and Traversable are both closed under composition,
meaning that `newtype Compose f g a = Compose (f (g a))` has the following
instances:

instance (Foldable f, Foldable g) => Foldable (Compose f g)

instance (Traversable f, Traversable g) => Traversable (Compose f g)

Removing the Foldable instance for `(,) e` would also remove the Foldable
and Traversable instance for any composition of functors containing tuples.
If you're writing your code in terms of fixed points of type constructors,
then this is a problem.

Matt Parsons

On Thu, May 4, 2017 at 2:52 PM, Chris Smith <cdsmith at gmail.com> wrote:

> My answer this is: because Foldable instances on tuples make Haskell
> programming more dangerous.
>
> With all instances, there is some risk of accidental unification with
> broken programs.  But in general, we are saved by one of two things: either
> the types are special-purpose enough that they are unlikely to occur by
> accident, or unification just propagates the incorrect type and the
> compiler merely puts the error message is in the wrong place.
>
> With length and tuples, though, we're talking about a type that's used
> casually in many situations; and the accidental unification does not
> propagate the type at all.  Instead, it just generates incorrect code.
> That's a bit scary!
>
> It's unfortunate that discussions of this tend to get muddied by the
> possibility of length having a different meaning on tuples.  Really, IMHO,
> that's not even related to the problem.  The problem is that accidental
> unification is more risky here than anywhere other commonly used bit of
> Haskell that I can find.
>
> On Thu, May 4, 2017 at 1:32 PM, MarLinn <monkleyon at gmail.com> wrote:
>
>>
>> This to me is the center of the conversation: we're choosing whether we need the instances badly enough that we tolerate some, ahem, bad behavior.
>>
>>
>> I dispute that. To me, the center of the disagreement is between two
>> different kinds of consistency: On the one hand, there's the consistency
>> with a view of the world that treats One as a special number different from
>> all other numbers. This view is based on the real world where singularities
>> seem rampant. On the other side is consistency with a math-y view of the
>> world that wants to unify as much as possible so we can reduce the number
>> of models, thus, work.
>>
>> But if you want to treat the cardinality of one specially, do you want to
>> drop Const and Identity, too? Const is closer to tuples than lists are, so
>> why not cut them out as well? But then we had examples in just this
>> conversation where Const and Identity where really useful. What argument is
>> left to remove instances for tuples? If you can get over the 5-second
>> weirdness of Const, why not tuples?
>> At the end I claim there is no bad behavior. I do give you that there is
>> *missing* behavior because the choice to have only that one instance per
>> tuple size is a bit arbitrary and misleading. And that is hard to change
>> for now. But do you really want to remove those few instances we do have
>> just because we're not ready to include the others yet?
>>
>> MarLinn
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170504/5d8be607/attachment.html>


More information about the Haskell-Cafe mailing list