Haskell Foldable Wats (Was: Add conspicuously missing Functor instances for tuples)

Thu Feb 18 07:41:50 UTC 2016

There are many of us who agree with you that this is a disaster.  It could have been avoided in several ways, but this what we got.

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Bart Massey
Sent: 17 February 2016 17:35
To: Henning Thielemann; Ryan Scott
Cc: Haskell Libraries
Subject: Re: Haskell Foldable Wats (Was: Add conspicuously missing Functor instances for tuples)

As a less-capable Haskeller, I agree 100%.

The whole point of importing Data.List (either directly or from the Prelude) is to get functions that work on lists. A crucial feature of this is that applying these functions to non-lists should generate type errors, so that I can notice that I passed e.g. a tuple where I meant to pass a list. I would be fine with adding Foldable versions of list functions to Data.Foldable: if I want my functions to work on arbitrary Foldables, that's what I would import.

As someone who spends some time teaching beginners Haskell, this is a disaster. Trying to explain to a beginner why "Data.List.length ('x', 'y')" returns a number instead of failing is bad enough: trying to explain why it returns 1 is hopeless. (I'm better off with Python: at least there it has the grace to return 2.) And then I have to explain why "length ('x', 'y', 'z')" returns an utterly incomprehensible type error? No thanks.

I'm recommending SML over Haskell to beginners a lot more these days.

On Wed, Feb 17, 2016 at 3:02 AM Henning Thielemann <lemming at henning-thielemann.de<mailto:lemming at henning-thielemann.de>> wrote:

On Mon, 18 Jan 2016, Ryan Scott wrote:

> * The Not-A-Wat in Haskell:
> https://www.youtube.com/watch?v=87re_yIQMDw

I see his examples and draw the opposite conclusions. What he presents are
perfect Wats and they have eventually moved Haskell to the MatLab league
where everything is allowed and the programming system accepts almost
everything the programmer enters.

Sure,

> length (2,3) = 1
> product (2,3) = 3
> sum (2,3) = 3
> or (True,False) = False

are all consistent but consistently useless, unintuitive (not only to
novices) and dangerous. There are alternatives: There was no need to
generalize 'Prelude.length' using Foldable. I always opposed to the
argument "put the most general variant to Prelude", because there is no
clear most general variant or there is one like "length :: Length f => f"
and you won't like it.

We could reasonably have the Haskell 98 class

   class Length a where
      length :: a -> Int

   instance Length [a] where
      length = List.length

   instance Length (a,b) where
      length _ = 2

This would yield the intuitive
   length (2,3) = 2

I do not propose to implement this class, because I never encountered a
situation where I could equally choose between lists and pairs. If at all,
I can see value in a special TupleSize class. However, the Length class
proves that the suggestion that the only reasonable result of 'length
(2,3)' is 1, is plain wrong.

How did we get there? There were three steps that made this Wat possible:
   1. Foldable.length added
   2. instance Foldable ((,) a)
   3. export Foldable.length from Prelude.

For me
   1. was correct
   2. was wrong because a programmer should better define a custom type
      like "data AdornedSingleton a b = AS a b"
   3. Was wrong because there are multiple ways to generalize 'length'.
      Without 3. you would have to use explicitly 'length' from Foldable
      and this way you would have been warned, that strange things may happen.
_______________________________________________
Libraries mailing list
Libraries at haskell.org<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160218/d25edbc5/attachment-0001.html>