[Haskell-cafe] Re: Tutorial on Haskell

Evan Laforge qdunkan at gmail.com
Mon Apr 16 19:54:13 EDT 2007

> - Parsec is not that interesting for those coming from perl, ruby, or
>   python as they rely on regular expressions for everything and just
>   expect that they are part of the language.  The thought of writing
>   one's own parser is not as "cool" as most Haskellers believe it is,
>   regardless of how interesting the parsec library is.

I would think the reverse... people who have used regexes a lot might
be interested in a technique that doesn't have their limitations.  For
example, you can define your own parsers (anyone who has had to deal
with REs of any complexity will appreciate that), you can "remember"
things (e.g. the classic eat chars until balancing paren thing), much
better error reporting (wouldn't a perler like to know where and how
his regex failed to match?) and then you're not limited to characters!

I gave a talk on haskell once and intended to include (unfortunately
ran out of time) a "write your own regexish language in 50 lines"
section using parser combinators (a simplified monadic setup with
regex style capturing groups).  Then show how I can define custom
parsers (e.g. match a number between x and y), recursive ones (match a
sexpr), and wind up with much more readable individually testable
expressions, e.g. "ip = let ipnum = group (num_in_range 0 255) in
ipnum >> dot >> ipnum >> dot >> ipnum >> dot >> ipnum" then "log_msg =
hostname >> ip >> blah" vs. the usual huge buggy regex.  And then I
can take the same operators and apply them to matching keywords to
e.g. match cmdline args for a simple specification language.

What you lose is the nice concise line-noise language, but then you
can show how easy it is to write a line noise -> parser combinator

It illustrates a few nice things about haskell: laziness for the
recursive defs and easy backtracking, low syntax overhead and custom
operators for DSLs, composability, etc.

More information about the Haskell-Cafe mailing list