On Fri, Dec 12, 2003 at 08:55:59PM +0000, Graham Klyne wrote:

At 14:17 12/12/03 -0500, Derek Elkins wrote:

...

This will also provide a migration path if you want a more featureful monad. (or_maybe is mplus, fail or mzero can be used for Nothing when you explicitly want to fail).

Is this or_maybe (and friends) actually defined in any of the standard libraries? (Google found only one hit, in an old IRC log.)

mplus and mzero are methods in class MonadPlus, which you'll found in module Monad. There is an instance of MonadPlus for Maybe. Best regards, Tom -- .signature: Too many levels of symbolic links

On Mon, Dec 15, 2003 at 08:55:10AM +0000, Graham Klyne wrote:

I apologize... my question was unclear.

It was not the standard MonadPlus class and functions that I was asking about, but the specific instance for Maybe (i.e. or_maybe). As it happens, a couple of times in the past couple of weeks, I might have used such a function if it were available in the standard libraries.

My or_maybe is just defined as or_maybe (Just e) _ = Just e or_maybe Nothing f = f which is pretty simple, so you can run a series of calculations (assuming you want to keep the first that has a non-Nothing result) using f = a `or_maybe` b `or_maybe` c -- David Roundy http://www.abridgegame.org

Hi David Roundy wrote:

On Mon, Dec 15, 2003 at 08:55:10AM +0000, Graham Klyne wrote:

...

I apologize... my question was unclear.

It was not the standard MonadPlus class and functions that I was asking about, but the specific instance for Maybe (i.e. or_maybe). As it happens, a couple of times in the past couple of weeks, I might have used such a function if it were available in the standard libraries.

My or_maybe is just defined as

or_maybe (Just e) _ = Just e or_maybe Nothing f = f

I've always been a little bothered by the MonadPlus class: zero and plus are associated (no pun intended) in my mind with monoidal structure. Is there more to MonadPlus than a clumsy workaround for the lack of quantified constraints? If we could have quantified constraints, e.g. (Monad m, forall x. Monoid (m x)) wouldn't that be better than having Monad-specific monoids? Of course, we can always kludge class MakesMonoid f where makesZero :: f x makesPlus :: f x -> f x -> f x instance MakesMonoid f => Monoid (f x) where mempty = makesZero mappend = makesPlus but that causes serious restrictions on the other monoids we can declare. One useful thing about monoids is that they can be lifted pointwise through product-like structures instance (Monoid x,Monoid y) => Monoid (x,y) instance Monoid t => Monoid (s -> t) -- note this conflicts with the more usual but (I claim) -- less useful Monoid (a -> a) The latter gives us higher-order combinators for the price of first-order operators. For example, given the `or_maybe' monoid, we get for free the operation which prioritizes two partial functions, trying the second only if the first fails. mappend :: (s -> Maybe t) -> (s -> Maybe t) -> (s -> Maybe t) You'd also be amazed how useful the monoid IO () can be... So I guess this is yet another plea for universally quantified constraints. Is there a problem with them? I don't see why (forall x. Monoid (m x)) is harder to check than (Monoid (m FreshName)). Of course, the next thing after quantified constraints is constrained constraints, and a big chunk of lambda-Prolog appearing as one of Haskell's growing collection of heterogeneous compile-time programming languages. What a big can of tasty worms... Cheers Conor

...

...

...

...

"Graham" == Graham Klyne writes:

Graham> I apologize... my question was unclear. It was not the Graham> standard MonadPlus class and functions that I was asking Graham> about, but the specific instance for Maybe (i.e. or_maybe). Graham> As it happens, a couple of times in the past couple of weeks, Graham> I might have used such a function if it were available in the Graham> standard libraries. I think there has been some misunderstanding here. What the other posters wrote is that it is definitely available, but under the "mplus" name. If you want the "or_maybe" name, you can define it as: or_maybe :: Maybe a -> Maybe a -> Maybe a or_maybe = mplus but you should rather use "mplus" where you would instead use "or_maybe" because not only is "mplus" standard (you have to "import Monad"), also it allows you to use something else than "Maybe" later if you need to. So, in short: the "or_maybe" you are looking for is already available, but you should spell it "mplus". Sam -- Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

On Fri, 12 Dec 2003 20:55:59 +0000 Graham Klyne wrote:

At 14:17 12/12/03 -0500, Derek Elkins wrote:

...

This will also provide a migration path if you want a more featureful monad. (or_maybe is mplus, fail or mzero can be used for Nothing when you explicitly want to fail).

Is this or_maybe (and friends) actually defined in any of the standard libraries? (Google found only one hit, in an old IRC log.)

Well, I was somewhat confusing in switching the order, but or_maybe is a specialization of mplus. mplus is the general standard function and or_maybe is David's specialized to Maybe version. http://www.haskell.org/onlinereport/monad.html The idea of the operations of the MonadPlus class is mzero typically stands for some kind of failure and mplus is a choice or a merging. A logic analogy is if a >> b >> c is do a and b and c then a `mplus` b `mplus` c is do a or b or c. mzero would be false and return x would be true. Examples of things that would be instances of MonadPlus are: lists as representing non-determinism where mzero is [] meaning no answers (failure) and mplus being non-deterministic choice represented as (++), parsers with mzero as the always failing parser and mplus as alternation (Parsec's <|>), concurrency with mzero as the process that immediately halts and mplus as par (run two processes in parallel).