On Tue, Oct 20, 2009 at 11:04 AM, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:

On Sun, Oct 18, 2009 at 9:45 PM, Michael Snoyman <michael@snoyman.com> wrote:
> While working on the next release of data-object, I wanted to represent some
> operations that might fail. The typical candidates were:
>
> 1) Maybe
> 2) Either
> 3) Monad
>
> Monad is always iffy because of the often times poorly defined fail. Maybe
> doesn't provide any means of reporting what the problem was. Either is not
> defined as a Monad in the base library. Also, the usual candidate of Either
> String only provides for an error message. It would be nice to have more
> in-depth information available.
>
> So I've put together a package I call "attempt". It defines a data type
> called (surprise) Attempt with a Success and Failure constructor. The trick
> here is that it using the new extensible exceptions under the surface, so
> you can report any kind of exception you want. It also provides a
> "FromAttempt" type class for possible conversion targets from an Attempt,
> provides an attempt function with some helpers for performing the equivalent
> of Control.Exception.catches, and provides two samples of functions I would
> want to implement with this library: attemptJoin and attemptLookup.
>
> My questions for the list are:
>
> 1) Is the overall approach sound, or do people have better ideas?

I think that there is a place for such a package. Given the Monad/fail issue,
the Maybe/no-message issue and the Either/not-a-monad-in-base issue.

About the name Attempt, I think that 'Outcome' would be a better name.

The problem with a name like "Outcome" is that it doesn't really imply the possibility of failure, simply that we are wrapping of the result for some reason.

> 2) Are there any other FromAttempt instances I should provide out of the
> box?

None that I see.

> 3) I was considering adding specialized versions of the fromAttempt
> function, ie ioFromAttempt, maybeFromAttempt. Thoughts?

It is a bit long to spell.

True, but it can be more convenient than giving explicit type signatures. The main reason this might come up would be regarding the (Either String) and (Either SomeException) instances.

> 4) Should I follow the naming scheme attemptJoin, attemptLookup, etc, or
> just call the functions join, lookup and force people to import the module
> qualified?

A nice alternative would be to make a Data.Attempt.Extra (or a better
name) which
would be imported qualified.

I like. The only other name I can think of right now is Data.Attempt.Helper, but that's just painting the bike shed.

> 5) Any other suggestions for attempt functions? I've considered
> head/tail/etc.

Why not, maybe the 'safe' package should be of some inspiration.

Once they're all in their own module, I don't see a problem adding as many as possible.

> 6) Include ToAttempt?

IMHO, no.

> The code is available on github at

I think that the 'attempt' function should follow functions like
'maybe' and 'either'.

attempt :: (forall e. Exception e -> b) -> (a -> b) -> Attempt a -> b

I was trying to more model it after fromMaybe, but instead just ended up with something ugly. I'm going to rewrite attempt using this type signature and then add fromAttempt as well.

Michael