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