Haskell Foldable Wast

Thu Feb 18 12:19:53 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.

-----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.