replacing guile with haskell?
GK at ninebynine.org
Thu Oct 23 10:18:26 EDT 2003
At 01:14 22/10/03 +0200, Peter Simons wrote:
>Graham Klyne writes:
> > I'm thinking in particular that a function that turned a regular
> > expression into a Parsec parser function could be useful, as in:
> > regexp.compile :: String -> GenParser Char st [String]
>Just curious: Why would you want something like that? I thought that
>the good thing(tm) about regular expressions is that they can be
>parsed by a finite state machine rather than a recursive descent
>parser, so for all I know, the C regular expression library that comes
>with your system is most likely much faster than any Parsec code would
The comment was motivated by my finding that Parsec to be very useful for
handling higher-level syntactic constructs, but dealing with lexical
constructs can be more complex. It had occurred to me that a
regexp-matching component could provide a useful ad-hoc lexer for parsec.
Another reason that occurred to me was that one can start out with a regexp
being a quick (and-maybe-dirty) way to get a textual value parsed. Then
increasing requirements, feature creep, etc., mean that the regexp ends up
getting embodied in ad-hoc code to deal with non-finite aspects of an
evolving syntax. If the regexp processing were already handled within the
Parsec framework, it seems to me a natural evolutionary path to use it with
other Parsec combinators.
These may not be good reasons, just the ones that happened to be in my head
when I made that comment.
I also noted ajb's comments about overloading of terminology here ... and
agree, I was using the term rather loosely ... in this case I was thinking
of the kind of regular expression that can be handled with a finite
automaton -- I've never mastered all the full complexities of
Perl-compatible regexes and the like. The extension of regexes beyond this
form is IMO symptomatic of the second of my points above.
More information about the Haskell-Cafe