#2309: containers: specialize functions that fail in a Monad to
josef.svenningsson at gmail.com
Thu May 29 05:51:43 EDT 2008
I also vote for Maybe. I have never used the feature for failing in
any other monad than Maybe.
On Thu, May 29, 2008 at 1:27 AM, Lennart Augustsson
<lennart at augustsson.net> wrote:
> And here's another vote for Maybe. That's almost always the return
> type that you want anyway, so the inconvenience in minimal.
> And anyone who wants the old behavior can easily make a utility
> function that provides it.
> The current behaviour encourages sloppy programming.
> -- Lennart
> On Wed, May 28, 2008 at 7:51 PM, Duncan Coutts
> <duncan.coutts at worc.ox.ac.uk> wrote:
>> On Wed, 2008-05-28 at 11:11 +0100, Conor McBride wrote:
>>> > Ross Paterson wrote:
>>> >> Several functions on containers used to have types like
>>> >> lookup :: (Ord k) => k -> Map k a -> Maybe a
>>> >> but these were generalized to
>>> >> lookup :: (Monad m, Ord k) => k -> Map k a -> m a
>>> >> The proposal is to change these signatures back, specializing them
>>> >> to Maybe.
>>> > I'm all for Maybe in the question Monad VS Maybe.
>>> Me too. (+1) for Ross's proposal.
>> If we need any more (+1) votes you can count mine.
>>> > Also, it's not entirely clear whether MonadZero is the most general
>>> > abstraction. Is ApplicativeZero better? Or something else?
>>> Maybe is the most general abstraction. Requiring
>>> (>>=), or even (<*>) seems excessive. What we need
>>> is "any f with zero and return", so why not pick
>>> the canonical, initial, inductively defined such
>> Good. I like that argument.
>> As others have pointed out, it's easy to lift maybe into something else
>> when that's needed.
>> maybe :: a -> (b -> a) -> Maybe b -> a
>> Libraries mailing list
>> Libraries at haskell.org
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries