[Haskell-cafe] Re: partial functions / failure,
Maybe and MonadError and good style
sdowney at gmail.com
Fri Dec 22 21:44:35 EST 2006
'normal execution path' is a key phrase here. If we're truely thinking
functionally, there is no execution path. At most there are evaluation
I suppose this is why Maybe is a monad rather than just another
algebraic data type.
Perhaps I'm thinking of the strategy of 'replacing failures by a list
of sucesses' where an empty list is possible.
This is exactly where I'm stuck. I've an eval1 function of ArithExpr
-> m ArithExpr, where m started out as Maybe. Now only the calling
eval function mentions Maybe. And I was wondering if I could keep
OTOH, eval1 should really pass through information from the underlying parser...
Really RSN. When me, my laptop, and my wireless connection all meet at
the same time.
On 12/22/06, Ross Paterson <ross at soi.city.ac.uk> wrote:
> On Fri, Dec 22, 2006 at 08:37:05PM -0500, Steve Downey wrote:
> > On 12/22/06, Stefan O'Rear <stefanor at cox.net> wrote:
> > >All monads provide a "fail" operation, and any function that uses fail
> > >be able to work with any monad's error handling mechanism.
> > >
> > >* Maybe - fail msg is Nothing (ignores the message)
> > >* Either str - fail msg is Left msg (stores the message)
> > >* IO - fail msg is ioError (userError msg) (throws message as
> > >exception)
> > OK, but is msg always a string?
> You've hit the nail on the head. The fail method is a kludge that works
> if the error is just a string (in English, of course), but often it isn't.
> > >For instance, Data.Map.minView is Monad m => Set a -> m (Set a, a); so..
> > >
> > >minView :: Set a -> Maybe (Set a, a) -- gives Nothing on empty set
> > >minView :: Set a -> [(Set a, a)] -- gives  on empty set
> > >minView :: Set a -> IO (Set a, a) -- throws an ioError on empty set
> > >...
> > >
> > >(note that the behavior of lookup et al, which are specific to Maybe, is
> > >considered outdated style)
> I feel a bit queasy about this. With the old Maybe type of minView,
> it really was a view: the empty case was an element of the data type,
> not an error. You could pattern match on it, and the empty case would
> often be perfectly normal. Of course you can still do that, because
> the old type is a special case that's still available, but the change
> of perspective gives the wrong impression, I think. It feels wrong to
> use failure as a normal execution path.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe