On Tue, Oct 20, 2009 at 5:17 PM, Nicolas Pouillard < nicolas.pouill...@gmail.com> wrote:
> On Tue, Oct 20, 2009 at 3:12 PM, Michael Snoyman <mich...@snoyman.com> > wrote: > > > > > > On Tue, Oct 20, 2009 at 11:04 AM, Nicolas Pouillard > > <nicolas.pouill...@gmail.com> wrote: > >> > >> On Sun, Oct 18, 2009 at 9:45 PM, Michael Snoyman <mich...@snoyman.com> > >> wrote: > >> > While working on the next release of data-object, I wanted to > represent > > [...] > > >> 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. > > I don't see why, the outcome of an action could be either a success or > a failure. > Even if the only *desired* outcome is success. > I think I'm going to stick with Attempt. The only other point that came to me is it's nicer to have a function called "attempt" than "outcome" IMO. > > >> > 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. > > I also prefer Helper. > Done. Not full-featured yet, but does provide a nice core. > > >> > 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. > > [...] > > >> 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. > > Fine, fromAttempt should follow fromMaybe > > fromAttempt :: (forall e. Exception e -> a) -> Attempt a -> a > fromAttempt f a = attempt f id a > And of course I now realize this name will conflict with the FromAttempt typeclass ;). I think we'll be safe leaving this function out, considering how trivial it is to implement in terms of attempt. Also, I've added a monad transformer to the github repo. I've tried it out in some local code I have, and it *really* cleans up the error handling. Michael
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe