[Haskell-cafe] Why Maybe exists if there is Either?

[Richard A. O'Keefe]

On 22/01/2014, at 10:23 PM, Joachim Breitner wrote:
> Am Mittwoch, den 22.01.2014, 14:56 +1300 schrieb Richard A. O'Keefe:
>> If there is _any_ sane way to reverse a Unicode string,
>> which I rather doubt,
>> it would be _horrible_ to implement it.
> 
> I suggest this:
> 
>> reverse unicode_str = '\u202E' : unicode_str
> 
> ‮It works great!

According to "Unicode Demystified",
   The Unicode bidirectional text layout algorithm (or
   "bi-di algorithm," as it is most commonly called)
   is possibly the most complicated and difficult-to-
   understand aspect of the Unicode standard.
Considering the rest of Unicode, that says a LOT.

This particular example using RIGHT-TO-LEFT OVERRIDE is a
neat hack, but as a *general* way to reverse strings it's
a FAIL:
	let s="\u202DIt's harder than you think."
	'\u202E' : s
You will see no reversal in the output.

Reverting to the original topic, Maybe and Either signify
different things to human beings, and in the original
libraries, the cost of having both was negligible compared
with the benefits.

Just recently I was revising some code in another language,
where they had the equivalent of

	infinity = 99999.0

to serve as the initial value in a "search for the cheapest
element and its cost" loop, and I suggested the equivalent
of using Maybe (Cost, Item) instead, on the grounds that when
you make up an "arbitrary" value it's a bad sign.  In fact
making this change led me to a deeper understanding of what
the algorithm could do and a clarifying shift in its structure.
(Amongst other things, the original code actually _relied_ on
infinity + finite > infinity, which is not the way infinities
are supposed to behave.)  Representing Maybe as Either with
an arbitrary value made up to be the "missing" value seems to
me like just such a bad sign.