Hi Brandon,

A nice example with NULL as usage. :-)  Missed that one in thinking.

> ... is letting the programmer do what they need to do with a minimum of fuss or extra work ...
But doesn't the need of mixing Maybe and Either cause more work for the programmer? Programmer of library, or programmer using the library?

I'll take a look at Control.Error package that seems to simplify mixing.


Thanks all you guys for your thoughts!


vlatko

-------- Original Message --------
Subject: Re: [Haskell-cafe] Why Maybe exists if there is Either?
From: Brandon Allbery <allbery.b@gmail.com>
To: Vlatko Bašić <vlatko.basic@gmail.com>
Cc: Johannes Erber <Hannes_E@gmx.de>, "haskell-cafe@haskell.org" <haskell-cafe@haskell.org>
Date: 09.01.2014 16:35


On Thu, Jan 9, 2014 at 10:26 AM, Vlatko Basic <vlatko.basic@gmail.com> wrote:
I put String because I'm currently thinking about error handling, and Left String is the usual way of reporting failure, and I see Maybe as a type for reporting errors, failures and similar.

Actually, the fact that all you can convey is "something failed" makes Maybe not a good error reporting type. And this is fine; there is still the "no value" niche (Perl's undefined, SQL's NULL, etc.) --- and the evidence from C's NULL that an *out of band* representation is often a very good idea (and from IEEE754's NaN that multiple out of band values is often a very bad idea).

Also, a point that seems to often be missed in considering what is "more important": ultimately, what is *most* important is letting the programmer do what they need to do with a minimum of fuss or extra work. Predefining very useful stuff like Maybe which could be reinvented on the fly based on Either is about minimizing even the trivial extra work. Pedagogy is only rarely a useful design goal.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net