Here is one. Re: Parser generator that supports regular expressions?

ipser@solomon.technet.sg (Ed Ipser)
Tue, 23 Jun 1992 02:29:50 GMT

          From comp.compilers

Related articles
Parser generator that supports regular expressions? stickler@utrio.helsinki.fi (1992-06-12)
Re: Parser generator that supports regular expressions? N.Chapman@cs.ucl.ac.uk (Nigel Chapman) (1992-06-22)
Here is one. Re: Parser generator that supports regular expressions? ipser@solomon.technet.sg (1992-06-23)
| List of all articles for this month |

Newsgroups: comp.compilers
From: ipser@solomon.technet.sg (Ed Ipser)
Keywords: parse, LR(1)
Organization: TECHNET, Singapore
References: 92-06-049 92-06-111
Date: Tue, 23 Jun 1992 02:29:50 GMT

Nigel Chapman <N.Chapman@cs.ucl.ac.uk> writes:
>> Does anyone know of a YACC-like parse generator that allows regular
>> expressions in rules (i.e. iteration, optionality, disjunction, grouping,
>> etc.).


Yes. LADE, a commercially available translator generator toolkit, allows
regular expressions in rules including: iteration, optionality,
disjunction, and grouping. (Contact: xorian@solomon.technet.sg)


>Not exactly, but I know why you're unlikely to find one in a hurry, if you
>specially want to use an LR parser generator. If you use regular
>expressions on the rhs of productions, then the subject of that production
>can generate a potentially infinite set of strings, of arbitrary length.


Which is exactly why they are so useful. Not only do they increase the
expressive power of the grammar grammar but they also simplify translation
and, in many cases, remove conflicts in grammars that would otherwise have
to be resolved by macroexpansion of productions or other tricks. (For a
pathalogical example, see the Roskind C++ grammar. Regular expressions in
LR parsers allow the parser to defer choosing between "potentially
infinite set of strings, of arbitrary length" until reduction; it
magnifies the very strengths of LR parsing.)


>On the other hand, using regular expressions in grammars for recursive
>descent is quite straighforward, and makes the parsers nicer too.


At the expense of the power of LR parsing. Why make the trade-off if you
don't have to?
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.