replacing guile with haskell?

[Graham Klyne]

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
>every be.

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.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact