On Tue, Jun 29, 2010 at 10:18 AM, Stephen Tetley wrote:

Hi Michael

If you going to the trouble of constructing a sum type (obliged to be 2 parameter) expressly to play well with the favourite single parameter classes e.g. Functor/ Applicative / Monad [*], maybe it is worth considering new names for the type and its constructors relating to what the Applicative/Monad instances actually model.

I'm definitely open to such an approach, but I couldn't come up with any good names ;). I'm open to suggestions.

As an aside, my wife is a classics major (Greek and Latin), and she recommended I name the constructors "Sinister" and "Dexter". Michael

* Stephen Tetley [2010-06-29 12:02:45+0100]

The "Applicative Programming with Effects Paper" has the "monodial accumulating" applicative instance on a sum type Conor McBride and Ross Paterson call Except:

data Except err a = OK a | Failed err

The names are nice and to the point, but they would equally describes the other exception model (monadic - exit on first fail) and having both might be particularly confusing to newcomers: two error types - one with an obvious name, one with an unfamiliar one, the unfamiliar one might be the one they need most often...

On a slightly related note, in my projects I tend to define my own Error-like types with descriptive names, often more than one failure mode and apropriate instances. For an example of this approach, see http://github.com/feuerbach/loker/blob/master/testingtool.hs#L33 -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain

* Vo Minh Thu [2010-06-29 16:26:06+0200]

2010/6/29 Roman Cheplyaka :

...

* Stephen Tetley [2010-06-29 12:02:45+0100]

...

The "Applicative Programming with Effects Paper" has the "monodial accumulating" applicative instance on a sum type Conor McBride and Ross Paterson call Except:

data Except err a = OK a | Failed err

The names are nice and to the point, but they would equally describes the other exception model (monadic - exit on first fail) and having both might be particularly confusing to newcomers: two error types - one with an obvious name, one with an unfamiliar one, the unfamiliar one might be the one they need most often...

On a slightly related note, in my projects I tend to define my own Error-like types with descriptive names, often more than one failure mode and apropriate instances. For an example of this approach, see http://github.com/feuerbach/loker/blob/master/testingtool.hs#L33

From a quick glance at it, I believe it would be easier to use

Either MyError MyResult

and then have

data MyError = All | The | Possible | Descriptive | Errors

I would have to have separate constructor for satisfying Error class constraint, which I don't want to deal with later. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain

On Tue, Jun 29, 2010 at 02:56:18PM -0500, Jeremy Shaw wrote:

On Jun 29, 2010, at 6:02 AM, Stephen Tetley wrote:

...

The "Applicative Programming with Effects Paper" has the "monodial accumulating" applicative instance on a sum type Conor McBride and Ross Paterson call Except:

data Except err a = OK a | Failed err

The applicatives-extra package defines a type:

type ErrorMsg = String data Failing a = Failure [ErrorMsg] | Success a

Which is a less general version of that type.

There's also a generalization, which I was going to put in transformers, but couldn't decide on the best name: data Sum p a = Return a | Others (p a) instance Functor p => Functor (Sum p) where fmap f (Return x) = Return (f x) fmap f (Others m) = Others (fmap f m) instance Applicative p => Applicative (Sum p) where pure = Return Return x <*> Return y = Return (x y) Return x <*> Others my = Others (x <$> my) Others mx <*> Return y = Others (mx <*> pure y) Others mx <*> Others my = Others (mx <*> my) instance Alternative p => Alternative (Sum p) where empty = Others empty Return x <|> _ = Return x Others _ <|> Return y = Return y Others mx <|> Others my = Others (mx <|> my)