Thank you all for the answers. It seems that a recurring reason is that
being defined as a general type, Either can be used not only to handle
errors, but choice in general. This, however, seems to make Either to
overloaded in my opinion. If I decide that I want to use Either as a way
to signal error, but a third party accepts Either for something
different, then things will probably not work.
I have little experience with Haskell, but I haven't seen Either used in
contexts other than error/success. If you could point me to some piece
of code that uses it in a different way it would be great.
I'll probably use something different as an internal representation of
failure in my programs, and only keep Either for the public API. Just my
thoughts for the moment...
On 5/27/10 6:26 PM, C. McCann wrote:
On Thu, May 27, 2010 at 10:25 AM, Ionut G. Stan<ionut.g.s...@gmail.com> wrote:
I was just wondering if there's any particular reason for which the two
constructors of the Either data type are named Left and Right. I'm thinking
that something like Success | Failure or Right | Wrong would have been a
little better.
Because that would confuse matters when using the type for something
other than representing success or failure.
Either is a generic sum type. That is, "Either A B" only means "either
you have an A, or you have a B". Use of Left to represent failure is
merely a matter of convention. Similarly, the generic product type in
Haskell is the 2-tuple--"(A, B)" only means "you have both an A and a
B".
Left and Right work well because they don't carry much extra semantic
baggage, and they make it easy to remember which type parameter goes
with which constructor. Other than the mnemonic value, something even
more bland like This and That would work as well.
Personally, I advocate instead using "Sinister" and "Dexter". Nice and
catchy, don't you think?
- C.
--
Ionuț G. Stan | http://igstan.ro
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
