Haskell Foldable Wast

Erik Hesselink hesselink at gmail.com
Mon Feb 22 10:32:27 UTC 2016


What will the signature of things like 'mapM_' be then? Will there be
two versions, one with a Foldable constraint and one with a
Traversable constraint?

I don't think base will be the area with the most impact here, by the
way. The biggest impact will be libraries using these classes, where
suddenly more class constraints need to be added to the signature.

Erik

On 22 February 2016 at 08:33, Augustsson, Lennart
<Lennart.Augustsson at sc.com> wrote:
> I don’t believe the practical consequences will be severe.  I know you do,
> but you have provided no proof.
>
> I did an experiment and removed it, and recompiled base.  And it hardly
> needed any changes.
>
>
>
> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Edward
> Kmett
> Sent: 21 February 2016 23:51
> To: Jeremy
> Cc: Haskell Libraries
> Subject: Re: Haskell Foldable Wast
>
>
>
> That leads to a ton of ever MORE nonsensical consequences like not being to
> weaken calls to mapM (which uses Traversable) to mapM_(which needs only
> Foldable) or doubling the number of combinators we have all over again for
> random prescriptive reasons, right after we just starting finally healing
> the last source of needless duplication (Applicative not being a superclass
> of Monad).
>
>
>
> -Edward
>
>
>
> On Sun, Feb 21, 2016 at 7:57 AM, Jeremy <voldermort at hotmail.com> wrote:
>
> Marcin Mrotek wrote
>> I think that, as far as Foldable is concerned, a tuple is equivalent to
>> Identity, so this instance is indeed useless. However, Foldable is a
>> superclass of Traversable (and it wouldn't make much sense to make these
>> classes unrelated, as one can always define folds with `traverse`), so
>> I've
>> always found it a necessary evil.
>
> Perhaps the case of tuple is evidence that Foldable should *not* be a
> superclass of Traversable?
>
>
>
> --
> View this message in context:
> http://haskell.1045720.n5.nabble.com/Proposal-Add-conspicuously-missing-Functor-instances-for-tuples-tp5827530p5830710.html
>
> Sent from the Haskell - Libraries mailing list archive at Nabble.com.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>
> This email and any attachments are confidential and may also be privileged.
> If you are not the intended recipient, please delete all copies and notify
> the sender immediately. You may wish to refer to the incorporation details
> of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html
>
> Insofar as this communication contains any market commentary, the market
> commentary has been prepared by sales and/or trading desk of Standard
> Chartered Bank or its affiliate. It is not and does not constitute research
> material, independent research, recommendation or financial advice. Any
> market commentary is for information purpose only and shall not be relied
> for any other purpose, and is subject to the relevant disclaimers available
> at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx
>
> Insofar as this e-mail contains the term sheet for a proposed transaction,
> by responding affirmatively to this e-mail, you agree that you have
> understood the terms and conditions in the attached term sheet and evaluated
> the merits and risks of the transaction. We may at times also request you to
> sign on the term sheet to acknowledge in respect of the same.
>
> Please visit
> http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx
> for important information with respect to derivative products.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>


More information about the Libraries mailing list