Haskell Foldable Wast

Thu Feb 18 12:26:34 UTC 2016

> I'm afraid that ship has sailed.  And as the Haskell ship steams towards new glorious horizons, I'm afraid sanity and restraint were left on the shore.

> What's left now is to either stay with an older version of ghc or fork everything.
> Or embrace crazy, of course.

As opposed to the crazy of leaving an entire language or staying on
old, unsupported versions because of one small piece (a single
instance of a single typeclass) you disagree with?

On Thu, Feb 18, 2016 at 1:19 PM, Augustsson, Lennart
<Lennart.Augustsson at sc.com> wrote:
> I'm afraid that ship has sailed.  And as the Haskell ship steams towards new glorious horizons, I'm afraid sanity and restraint were left on the shore.
>
> What's left now is to either stay with an older version of ghc or fork everything.
> Or embrace crazy, of course.
>
> -----Original Message-----
> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Henrik Nilsson
> Sent: 18 February 2016 10:54
> To: amindfv at gmail.com; Henning Thielemann; Haskell Libraries; Ryan Scott; johnw at newartisans.com
> Subject: Re: Haskell Foldable Wast
>
> Hi,
>
> John Wiegley wrote:
>
>  > I think the fact that toList (3,4) has a meaning that is not obvious  > to the layman is a teaching matter.
>
> Well, I would not characterise many of those who have raised concerns about this as "laymen".
>
> With a couple of decades of Haskell and CS teaching experience, and a couple more of general programming experience, I don't consider myself a layman either (and I hope that does not come across as arrogant).
>
> Yet, things like:
>
>  > length (1, 2) = 1
>  > fold ("foo", "bar") = "bar"
>  > toList (3,4) = [4]
>  > elem 1 (1,2) = False
>
> simply makes no sense to me whatsoever: neither intuitively, nor in terms of compelling practical use cases.
>
> And as to teaching this to a class: well, if we want to stop our students from considering Haskell as a serious programming language, I can see no better way than the above. Our students here would be in laughing fits throughout their degrees.
>
> I read (x,4), in a Foldable
>  > context, as an "annotated 4", and not as some kind of shorthand for a  > two-element collection.
>
> Personally, if I wanted to introduce annotated numbers, I'd introduce a new type to clearly convey that idea. Yes, a bit more to write, but the end result is code that conveys the ideas behind it in a clear manner. After all, code is (broadly) written once, but read many times.
>
> As to making tuples functor instances, that can only be done by arbitrarily imbuing one of the fields with a special status.
> I have to ask: Why? After all, taking pairs as an example, the
> *essence* of a pair is that there are two projection functions, one for each field.
>
> So, if I am now interested in applying a function to the fields, why should only one of the fields be granted that privilege?
> That's just not symmetrical and goes against the very idea of tuples.
>
> And whenever I have wanted to map on tuple fields (which I do from time to time), I most certainly want the ability to map on any field.
>
> As to tuples as instances of foldable: Why?  There isn't any structure to fold!
>
> By all means, if some care about making tuples be instances of functor and foldable etc., put those instances in a separate module, thus saving the rest of the (Haskell) world from the cognitive burden of even beginning to make any useful sense of
>
>     length (1, 2) = 1
>
> And allowing us to spend valuable teaching time on aspects of Haskell that actually might persuade our students to take Haskell seriously.
>
> Best,
>
> /Henrik
>
> --
> Henrik Nilsson
> School of Computer Science
> The University of Nottingham
> nhn at cs.nott.ac.uk
>
>
>
>
> 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
> 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