Beginners Digest, Vol 15, Issue 9
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.eduwrote: 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.eduwrote: 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
Beginners Digest, Vol 15, Issue 10
...). Now you point out that fail is not always properly defined. I quite agree with that. Nonetheless, in the simple cases I am trying to address here, it is IMO the best option available. If you end up using the function only with monads that properly define fail, then all the better. Michael -- next part -- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/beginners/attachments/20090915/c1c0e99e/attachment-0001.html -- Message: 3 Date: Wed, 16 Sep 2009 02:59:36 +0900 From: Yusaku Hashimoto nonow...@gmail.com Subject: Re: [Haskell-beginners] Maybe, Either To: Conor McBride co...@strictlypositive.org Cc: beginners@haskell.org Message-ID: d17c24b90909151059y4ec668edy5145e8706613d...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 If I understood your post correctly, you said - generalizing lookup to MonadPlus or Alternative or such classes are not necessary - use Maybe as usual, we should use adapters as we need Conor, You have said this many times elsewhere, but unfortunatelly, I heard it for the first time =) so please correct me if I'm wrong. I thought generalizing lookup is good example for usage of the MonadPlus as I read in RWH[1], but you said it's not necesarry. Now, I understood there are two positions for such classes. One is using generalizing for it, another is not. So, I want to know that when such classes should be used from later position. Heinrich suggested that is for overloading. But do any other usages are exist? [1]: http://book.realworldhaskell.org/read/programming-with-monads.html#VCard.hs:lookupM Cheers -nwn On Tue, Sep 15, 2009 at 5:21 PM, Conor McBride co...@strictlypositive.org wrote: 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 ___ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners -- Message: 4 Date: Tue, 15 Sep 2009 23:21:46 +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: 29bf512f0909151321u616c63b4p81e89b093b370...@mail.gmail.com Content-Type: text/plain; charset=utf-8 On Tue, Sep 15, 2009 at 3:08 AM, Brent Yorgey byor...@seas.upenn.eduwrote
