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
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
