begin C. McCann quotation:

Personally, I advocate instead using "Sinister" and "Dexter". Nice and catchy, don't you think?

Has anyone done a "translation" of the Prelude into Latin?

modulus PraeLudus ubi

data Uter a b = Sinister a | Dexter b derivare (Aequo, Ordinaro, Lego, Monstro)

Ha. -md

On 2010-05-27, aditya siram wrote:

...

Monstro I'm going to call it that from now on. Stay out of the IO Monstro.

Monstro is "Show" (think "demonstrate"), not "Monad". -- Aaron Denney -><-

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

Ionut G. Stan wrote:

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.

It's unlikely that the types would be compatible, unless you're using a type like Either String String. In that case, the solution may not be to switch to something other than Either, but rather to make the type more precise, like Either MyError MyValue, which can't be confused with other uses of Either. Keep in mind that a major point of the polymorphic type system in a language like Haskell is to be able to write typed code once and reuse it as widely as possible, so you should expect something as basic as choice between two alternatives to be represented by a very general type. A big advantage of using Either in a case like this is that any code written to operate on a general enough version of that type, such as "Either a b", may work just fine on your particular use of Either. That includes code which implements error monads, like these: http://hackage.haskell.org/packages/archive/transformers/0.2.1.0/doc/html/Co... http://hackage.haskell.org/packages/archive/mtl/1.1.0.2/doc/html/Control-Mon... or e.g. the Either utilities in MissingH: http://hackage.haskell.org/packages/archive/MissingH/1.1.0.3/doc/html/Data-E... By using Either, you're using the natural Haskell type for representing choice between two alternatives, that allows you to benefit from much of the code that's been written to use that type.

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.

Choice between two alternatives is a pretty common requirement - think of it as the datatype equivalent of an 'if' expression. As a result, it's used quite a lot. There's an example in the main GHC driver program, http://darcs.haskell.org/ghc/ghc/Main.hs : type Mode = Either PreStartupMode PostStartupMode type PostStartupMode = Either PreLoadMode PostLoadMode Notice that it's not possible to confuse those types with something else. Further, using an alias defined with 'type', as in the above example allows you to name your type something relevant to your program, without losing the benefits of using a general type like Either. Anton

2010/5/28 Donn Cave :

Quoth Ivan Lazar Miljenovic ,

...

  Whilst the Either type isn't officially used for errors, that is how it is usually treated in Haskell with the consensus that Left = failure and Right = success (note that due to how its defined it also has to be this way for Either's Monad instance to work).

I'm glad you mentioned that, I was going to mention how natural it would seem for Either to be an instance of Monad, given that it is used as you say by consensus for errors ... but something seems to be wrong with my libraries:

   No instance for (Monad (Either [Char]))      arising from a use of `return' at except.hs:25:24-29    Possible fix:      add an instance declaration for (Monad (Either [Char]))

So, I understand how to make a Monad instance, and I guess your point stands (as demonstrated by the expected type of (Either String)), but it's funny that Either is understood to have a Monad instance even though that's only implied, and not supplied.

[snip]

Hi, Control.Monad.Error provides an instance for Either. Cheers, Thu

On Friday 28 May 2010 20:44:20, Donn Cave wrote:

Quoth Vo Minh Thu , ...

...

Control.Monad.Error provides an instance for Either.

... in the mtl transformer library, in case anyone else besides myself didn't know that. And I see it has to be there because it depends on the Error typeclass.

Which is considered a wart by some. (Either left) has a perfectly valid Monad instance for any type left (the only slightly difficult thing might be 'fail').

(So the documentation for Control.Monad.Error, is mistaken, where at the top it says

Example type: Either String a

... which should be

Either Error a

... ?

No, String is an instance of Error, so (Either String) is fine.

Though I can't really be sure what the documentation is trying to say.)

In that case, have a look at the code, perhaps that is clearer. (And bug the maintainer(s) to improve the docs.)

Donn Cave, donn@avvanta.com

On Saturday 29 May 2010 01:28:59, Ivan Lazar Miljenovic wrote:

Daniel Fischer writes:

...

On Friday 28 May 2010 20:44:20, Donn Cave wrote:

...

Quoth Vo Minh Thu , ...

...

Control.Monad.Error provides an instance for Either.

... in the mtl transformer library, in case anyone else besides myself didn't know that. And I see it has to be there because it depends on the Error typeclass.

Which is considered a wart by some. (Either left) has a perfectly valid Monad instance for any type left (the only slightly difficult thing might be 'fail').

Though how would you set the Left value for some arbitrary type?

That is the difficult thing. If you want to have instance Monad (Either e) where ... , there are only two possibilities for fail that I see, fail msg = error msg -- or error somethingElse fail msg = Left undefined -- or Left (error msg) Neither is entirely convincing, but the second is a little more robust (though you can't inspect failures without catching exceptions). Constructing more meaningful Left values is then a little dangerous (if you try to inspect them) or pointless (if not). But if you want to have instance Monad (Either ConcreteType) where ... , you can have fail msg = Left someDefaultValue (or let the value depend on the message) and you can construct Left someMeaningfulValue in concrete situations. Of course, you can then also write instance Error ConcreteType where noMsg = someDefaultValue strMsg msg = whatever which really is no more fuss, so the 'bad' thing about it is just that if you want a Monad instance for (Either ConcreteType), you have to - import Control.Monad.Error(.Class) and make ConcreteType an instance of Error, or - make sure it's never used in the same module as C.M.E, or - enable OverlappingInstances when they're used together. Need I explain why I prefer the first?

...

...

Though I can't really be sure what the documentation is trying to say.)

In that case, have a look at the code, perhaps that is clearer. (And bug the maintainer(s) to improve the docs.)

IIRC, the basic point is that the Left type has to be one which can be converted from some arbitrary String value, to take into account the fail method for that type:

fail :: (Monad m) => String -> m a

Yep.

On Saturday 29 May 2010 02:26:38, Ivan Lazar Miljenovic wrote:

Daniel Fischer writes:

...

But if you want to have

instance Monad (Either ConcreteType) where ...

, you can have

fail msg = Left someDefaultValue

(or let the value depend on the message) and you can construct Left someMeaningfulValue in concrete situations.

Which happens to make it identical to Maybe ;-)

If you use only the default value. But if you use more, making your type an instance of Error would be the sensible thing (unless you're one of the mtl-haters, but probably transformers has a similar instance).

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.

One example use case is datatype-generic programming.

{-# LANGUAGE TypeFamilies #-}

Suppose I have a type class that gives me a unique representation for a type. The functions 'from' and 'to' allow me to convert from a value of that type to a value in its representation. An instance of 'Representable' should encode an isomorphism between some type 'a' and its representation type 'Rep a'. An isomorphism means that we can translate between 'a' and 'Rep a' without losing important information such as the structure of the value.

class Representable a where type Rep a from :: a -> Rep a to :: Rep a -> a

I can establish some types from the Haskell Prelude as representations for other types. Here, I use the "unit" type (), 'Either' as is the topic of the current thread, and the pair type (,).

instance Representable () where type Rep () = () from = id to = id instance (Representable a, Representable b) => Representable (Either a b) where type Rep (Either a b) = Either a b from = id to = id instance (Representable a, Representable b) => Representable (a, b) where type Rep (a, b) = (a, b) from = id to = id

The reason that I pick (), 'Either', and (,) is that we can represent many typical Haskell user-defined datatypes with these so-called basic types. A simple example is 'Bool'. In this case, the representation type for 'Bool' is 'Either () ()' since 'Bool' can be either 'True' or 'False'. The constructors of 'Bool' take no arguments, so we can use () to fill in the arguments for the 'Left' and 'Right' constructors of 'Either'.

instance Representable Bool where type Rep Bool = Either () () from x = case x of False -> Left () True -> Right () to x = case x of Left () -> False Right () -> True

Here is a more interesting example with constructors that take zero, two, and three arguments.

data MyType a b = Zero | Two a a | Three a b a

In order to represent 'MyType', we use nesting of 'Either' and pairs. This allows us to utilize the basic types defined above to represent more complicated types.

instance Representable (MyType a b) where type Rep (MyType a b) = Either () (Either (a, a) (a, (b, a))) from x = case x of Zero -> Left () Two a1 a2 -> Right (Left (a1, a2)) Three a1 b1 a2 -> Right (Right (a1, (b1, a2))) to x = case x of Left () -> Zero Right (Left (a1, a2)) -> Two a1 a2 Right (Right (a1, (b1, a2))) -> Three a1 b1 a2

Now, what's the real point of all this? Well, if we can define functions over the basic types (unit, 'Either', and pair), we can easily extend those functions to other types that can be represented by the basic types. Some canonical examples are equality and ordering. There already exist instances for the basic types, so defining instances for 'MyType' is trivial. We simply convert each 'MyType' value into its representation as defined above. The functions then act on the representation value.

instance (Eq a, Eq b) => Eq (MyType a b) where x == y = from x == from y

instance (Ord a, Ord b) => Ord (MyType a b) where compare x y = compare (from x) (from y)

You might say that we already have "deriving (Eq, Ord)," and that's true. But the implementation of deriving is specified by the Language Report and built into each compiler. If you come up with a new generic function, you won't have deriving for that. It's also (currently) much easier to write the above than to build a new deriving implementation for a compiler. There are many examples of generic functions and uses of datatype-generic concepts in Haskell. Just search Hackage for "generics." Regards, Sean