[clean-list] Clean in the Real World

[fzuurbie@inter.nl.net]

This is a multi-part message in MIME format.

--_----------=_107338153996314
Content-Disposition: inline
Content-Length: 1367
Content-Transfer-Encoding: binary
Content-Type: text/plain

Tomas wrote:
> On the other hand, they can lead to very elegant programs. IO is not the
> only monad. You can write purely functional code using monads. They can
> reduce the complexity of code - for example take monadic parser
> combinators.
> 
> I know you can design a non-monadic parser combinator library, but
> monadic parsers are really nice when you have syntactic sugar for them.

I am in the process of designing and applying a parser combinator library (yet another ..) - without the do-notation of course; Clean does not have it.

In my library there is only one combinator that you could call monadic: the 'followed by' combinator that takes the result of the first parser as an argument for the second parser.

The PARSEC library gives examples of parser applications all written in do-notation and I find it horrible. Do-notation easily turns a one-line parser into say a six-liner: the PARSEC authors felt tempted to insert a line break after each 'line' in a do-section. Also, this forced do-notation introduces a lot of explicit names of variables (on the left hand side of the <- arrows) that would go happily unnamed in a non-monadic parser-library.

Maybe there are places where monads are the way to go for elegant programming, but I have not found one yet. To me it is not IO and not combinator parsing.

Regards Erik Zuurbier 
--_----------=_107338153996314--