Send Beginners mailing list submissions to
        beginners@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
        beginners-requ...@haskell.org

You can reach the person managing the list at
        beginners-ow...@haskell.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1. Re:  Maybe, Either (Michael Snoyman)
   2. Re:  Maybe, Either (Michael P Mossey)
   3. Re:  Maybe, Either (Brent Yorgey)
   4. Re:  Maybe, Either (Brandon S. Allbery KF8NH)
   5. Re:  Maybe, Either (Yusaku Hashimoto)
   6. Re:  Maybe, Either (Conor McBride)
   7.  Re: Maybe, Either (Heinrich Apfelmus)


----------------------------------------------------------------------

Message: 1
Date: Mon, 14 Sep 2009 21:42:22 +0300
From: Michael Snoyman <mich...@snoyman.com>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Brent Yorgey <byor...@seas.upenn.edu>
Cc: beginners@haskell.org
Message-ID:
        <29bf512f0909141142m1d5129f0t6a744d691cc16...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Sun, Sep 13, 2009 at 3:40 PM, Brent Yorgey <byor...@seas.upenn.edu>wrote:

> On Sat, Sep 12, 2009 at 09:13:58PM +0300, Michael Snoyman wrote:
> > I often times have to write a lookup function that returns its value into
> > any monad instead of just Maybe. For example:
> >
> > mLookup :: (Eq k, Monad m) => k -> [(k, v)] -> m v
> > mLookup k pairs = case lookup k pairs of
> >                                 Nothing -> fail "mLookup: nothing found"
> >                                 Just v -> return v
> >
>
> This is actually the type that the lookup function USED to have, but
> it was changed since monads actually have nothing to do with failing
> (the fail method is just a hack used to handle pattern-match failures
> in do-notation).  Probably a better implementation of this would be
>
>  mLookup :: (Eq k, MonadPlus m) => k -> [(k,v)] -> m v
>  mLookup k pairs = maybe mzero return (lookup k pairs)
>
>
I understand that fail being in Monad is controversial, but my version of
the function works in *all* monads. This is very useful for:

1) Quickly writing up code in the IO monad (ie, for a shell script)
2) Check out the data-objects library; having an mLookup function makes
dealing with mappings very convenient.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.haskell.org/pipermail/beginners/attachments/20090914/437f6726/attachment-0001.html

------------------------------

Message: 2
Date: Mon, 14 Sep 2009 13:39:04 -0700
From: Michael P Mossey <m...@alumni.caltech.edu>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Michael Snoyman <mich...@snoyman.com>,      beginners
        <beginners@haskell.org>
Message-ID: <4aaea9e8.9070...@alumni.caltech.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed

Michael Snoyman wrote:
> Can you give me a better idea of what you mean by catching errors? That 
> could mean a lot of things.
> 
> Michael
Hi Michael,
I mean that I need my software not to exit the program on an error condition, 
but have a higher level "catch" of that condition which handles it gracefully. 
I'm writing a musical score editor for personal use in my spare hobby time. 
Because it's just a bit of spare time, I can't make a promise my software won't 
have bugs. When I'm working on a score, I don't want to lose my work when an 
error occurs, such as internal errors that violate the invariants I've 
established in my data structures. So any action that results in an error 
should 
trigger a message box that says "such-and-such error" and otherwise leave the 
data unchanged. Then I can save my work and attempt to debug the problem.

Thanks,
Mike



------------------------------

Message: 3
Date: Mon, 14 Sep 2009 20:08:08 -0400
From: Brent Yorgey <byor...@seas.upenn.edu>
Subject: Re: [Haskell-beginners] Maybe, Either
To: beginners@haskell.org
Message-ID: <20090915000808.ga12...@seas.upenn.edu>
Content-Type: text/plain; charset=us-ascii

On Mon, Sep 14, 2009 at 09:42:22PM +0300, Michael Snoyman wrote:
> On Sun, Sep 13, 2009 at 3:40 PM, Brent Yorgey <byor...@seas.upenn.edu>wrote:
> 
> > On Sat, Sep 12, 2009 at 09:13:58PM +0300, Michael Snoyman wrote:
> > > I often times have to write a lookup function that returns its value into
> > > any monad instead of just Maybe. For example:
> > >
> > > mLookup :: (Eq k, Monad m) => k -> [(k, v)] -> m v
> > > mLookup k pairs = case lookup k pairs of
> > >                                 Nothing -> fail "mLookup: nothing found"
> > >                                 Just v -> return v
> > >
> >
> > This is actually the type that the lookup function USED to have, but
> > it was changed since monads actually have nothing to do with failing
> > (the fail method is just a hack used to handle pattern-match failures
> > in do-notation).  Probably a better implementation of this would be
> >
> >  mLookup :: (Eq k, MonadPlus m) => k -> [(k,v)] -> m v
> >  mLookup k pairs = maybe mzero return (lookup k pairs)
> >
> >
> I understand that fail being in Monad is controversial, but my version of
> the function works in *all* monads. This is very useful for:

It doesn't work in *all* monads -- it only works in monads which
support a sensible notion of failure.  This is exactly what is
captured by the MonadPlus constraint on my version of mLookup.  And,
in fact, any monad in context of which you would want to use mLookup
(IO, Maybe, [], ...) are already instances of MonadPlus.

Also, fail being in Monad isn't controversial, it's just wrong. =) The
only controversial thing is what to DO about it now that it's there...

-Brent


------------------------------

Message: 4
Date: Mon, 14 Sep 2009 23:21:17 -0400
From: "Brandon S. Allbery KF8NH" <allb...@ece.cmu.edu>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Michael Snoyman <mich...@snoyman.com>
Cc: beginners@haskell.org
Message-ID: <a2c7cb11-8671-488c-85b8-e833d696f...@ece.cmu.edu>
Content-Type: text/plain; charset="us-ascii"

Skipped content of type multipart/alternative-------------- next part 
--------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : 
http://www.haskell.org/pipermail/beginners/attachments/20090914/cfd50e58/PGP-0001.bin

------------------------------

Message: 5
Date: Tue, 15 Sep 2009 15:14:28 +0900
From: Yusaku Hashimoto <nonow...@gmail.com>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Michael Snoyman <mich...@snoyman.com>
Cc: beginners@haskell.org
Message-ID:
        <d17c24b90909142314p43ae205aiaae2919a42a86...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

I prefer Alternative to MonadPlus for explaining failure. It has
better name and operator for failure and try-another.

import Control.Applicative

aLookup :: (Alternative f, Eq k) => k -> [(k,v)] -> f v
aLookup key pairs = maybe empty pure $ lookup key pairs

-nwn
On Tue, Sep 15, 2009 at 12:21 PM, Brandon S. Allbery KF8NH
<allb...@ece.cmu.edu> wrote:
> On Sep 14, 2009, at 14:42 , Michael Snoyman wrote:
>
> I understand that fail being in Monad is controversial, but my version of
> the function works in *all* monads. This is very
>
> Not really; "fail" in non-MonadPlus-es is a rather poorly defined notion,
> and there are no guarantees that the result will be at all sane.  "mzero" is
> well defined.
> --
> brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
> system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
> electrical and computer engineering, carnegie mellon university    KF8NH
>
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>


------------------------------

Message: 6
Date: Tue, 15 Sep 2009 09:21:02 +0100
From: Conor McBride <co...@strictlypositive.org>
Subject: Re: [Haskell-beginners] Maybe, Either
To: beginners@haskell.org
Message-ID:
        <3f9a8109-2b66-4791-9201-f635ee837...@strictlypositive.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Hi

This topic comes up a lot, and this is what I usually say when
it does. It's a thing I learned from James McKinna, many years
ago...

Might I gently suggest that there is a much better, more
natural way to abstract over every type-former which has
some sort of return/pure-like thing and some sort of mzero/empty
like thing? You could use the type-former which is inductively
defined to be the least such thing, and as such has a canonical
mapping to all the others, namely Maybe.

It's not necessarily a good idea to fix on Monad or MonadPlus
as there are other choices. For example,

On 15 Sep 2009, at 07:14, Yusaku Hashimoto wrote:

> I prefer Alternative to MonadPlus for explaining failure. It has
> better name and operator for failure and try-another.
>
> import Control.Applicative
>
> aLookup :: (Alternative f, Eq k) => k -> [(k,v)] -> f v
> aLookup key pairs = maybe empty pure $ lookup key pairs

there are notorious non-monadic instances for the above f
(some formulations of parsing, in particular). So,

>> I understand that fail being in Monad is controversial, but my  
>> version of
>> the function works in *all* monads.

this is a touch presumptuous. On the one hand, Brent is right
when he says

 > It doesn't work in *all* monads -- it only works in monads which
 > support a sensible notion of failure.

but he's perhaps excessive when he says

 > This is exactly what is captured by the MonadPlus constraint
 > on my version of mLookup.

because it's not exact: it requires mplus as well as a sensible
notion of failure. And yes, why should we insist on (>>=) when
we just need a return and an mzero?  Incidentally, I don't know
where the MonadPlus instance

 > (IO, Maybe, [], ...) are already instances of MonadPlus.

of IO is coming from, but I want it caught and locked up now (in
STM, for example) before it does any permanent damage.

Why not factor out the failure-prone operations from the business
of interpreting failure in some failure-supporting context? Work
concretely while you can (types stay shorter, error messages make
more sense) then apply adapters

malt :: Alternative f => Maybe x -> f x
malt = maybe empty pure

mop :: MonadPlus m => Maybe x -> m x
mop = maybe mzero return

when you need to? This also reduces the risk of connecting an
ambiguous supplier to an ambiguous consumer, (show . read) style.

The message clearly bears repeating. Inductive definition is
a concrete form of abstraction. Don't be fooled by its
appearance: Maybe is the most abstract choice here -- the
classier options demand more structure than is needed and
thus exclude use-cases.

I'll crawl back under my stone now.

All the best

Conor



------------------------------

Message: 7
Date: Tue, 15 Sep 2009 12:25:43 +0200
From: Heinrich Apfelmus <apfel...@quantentunnel.de>
Subject: [Haskell-beginners] Re: Maybe, Either
To: beginners@haskell.org
Message-ID: <h8nq39$u9...@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1

Conor McBride wrote:
>
> malt :: Alternative f => Maybe x -> f x
> malt = maybe empty pure
> 
> mop :: MonadPlus m => Maybe x -> m x
> mop = maybe mzero return
> 
> The message clearly bears repeating. Inductive definition is
> a concrete form of abstraction. Don't be fooled by its
> appearance: Maybe is the most abstract choice here -- the
> classier options demand more structure than is needed and
> thus exclude use-cases.

Seconded! Maybe is the most general choice.


The only issue left here would be that the combinators  malt  and  mop
are missing from the standard library. Once again, their purpose is not
generality, but the convenience of overloading.


Regards,
apfelmus

--
http://apfelmus.nfshost.com



------------------------------

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 15, Issue 9
****************************************

Reply via email to