RE: A propos de monad/About monads

From: Frank A. Christoph (christo@nextsolution.co.jp)
Date: Tue Oct 05 1999 - 07:48:53 MET DST


From: "Frank A. Christoph" <christo@nextsolution.co.jp>
To: "John Prevost" <prevost@maya.com>
Subject: RE: A propos de monad/About monads
Date: Tue, 5 Oct 1999 14:48:53 +0900
In-Reply-To: <m3ln9j2bx6.fsf@isil.maya.com>

> I spent some time last year working with monadic parsers--this is
> another really nice way to use monads (especially if you have monad
> comprehensions.)
> ...[example omitted]...

Ah! Parsers a great example of a useful monad without side-effects; I can't
believe I forgot to mention them. Actually, though, I have been using
Swierstra & Duponcheel's parser combinators (they are much more efficient)
for a while now and these, as is now well-known, cannot be expressed as a
monad.

Interested people can find out about them at:
 http://www.cs.uu.nl/groups/ST/Software/Parse/

> Unfortunately, this kind of thing (along with other higher-order
> combinator stuff for, as an example, formatted printing) doesn't work
> that well in ML because of the value restriction. :(

Yes. And maybe one reason I didn't mention parsers is that combinator
languages like this do not work as nicely in eager languages like ML as they
do in non-strict ones like Haskell. Aside from the fact that you have to
eta-expand lots of definitions, eager evaluation also forces you to turn
recursive operators like (say) the Kleene star into primitives, whereas in a
lazy regime you can define them at the object level, i.e., in terms of other
combinators. I guess you got around this by using the Lazy module...?

--FAC



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:26 MET