#2309: containers: specialize functions that fail in a Monad to
ndmitchell at gmail.com
Sun May 25 08:28:45 EDT 2008
>> If mzero, there's less gained over Maybe, but still no guarantee of
> If a program has a safety problem with mzero, that anyway
> needs to be detected. So I don't think that will have an
> effect on overall program safety, it's an orthogonal safety
I don't think this is the case.
mzero vs. Nothing
One doesn't crash, the other may crash depending on what is floating
around. Perhaps I've used type inference extensively, and the actual
decision of what mzero means is 10 functions away. Now its really
hard to see the program is safe, versus not.
Of course, if you use an automated thing, this is irrelevant
(traditional plug of Catch:
http://www-users.cs.york.ac.uk/~ndm/catch/) - but I think its still
useful for humans to be able to decide this easily.
> Other than minor convenience adavantages one way or
> the other depending on what program I happen to be writing,
> there is only one thing I can think of that might make a
> difference. Current compilers might produce programs that
> are slightly less efficient with MonadPlus, and there might
> be no easy way to work around that if MonadPlus is
> hard-wired into the library. Efficiency experts?
Discussions about the ideal and perfect API should not come down to
such minor considerations as efficiency :-) In reality, I don't think
it makes any difference, and in fact I think the Monad class might
make some things more efficient, as the class is likely to be
specialised away but returns of Maybe with a liftMaybe aren't likely
to be optimised out, as its essentially deforestation on a non-list
type, which GHC can't do (but something like Supero could
More information about the Libraries