Send Beginners mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Brent Yorgey <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
On Sun, Sep 13, 2009 at 3:40 PM, Brent Yorgey <[email protected]>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 <[email protected]>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Michael Snoyman <[email protected]>, beginners
<[email protected]>
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: [Haskell-beginners] Maybe, Either
To: [email protected]
Message-ID: <[email protected]>
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 <[email protected]>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" <[email protected]>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Michael Snoyman <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: [Haskell-beginners] Maybe, Either
To: Michael Snoyman <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
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
<[email protected]> 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] [email protected]
> system administrator [openafs,heimdal,too many hats] [email protected]
> electrical and computer engineering, carnegie mellon university   KF8NH
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
------------------------------
Message: 6
Date: Tue, 15 Sep 2009 09:21:02 +0100
From: Conor McBride <[email protected]>
Subject: Re: [Haskell-beginners] Maybe, Either
To: [email protected]
Message-ID:
<[email protected]>
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 <[email protected]>
Subject: [Haskell-beginners] Re: Maybe, Either
To: [email protected]
Message-ID: <[email protected]>
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
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 15, Issue 9
****************************************
