|language design implications for variant records in a pascal-like lang email@example.com (noitalmost) (2010-12-22)|
|Re: language design implications for variant records in a pascal-like firstname.lastname@example.org (George Neuner) (2010-12-23)|
|Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2010-12-31)|
|Re: language design implications for variant records in a pascal-like email@example.com (glen herrmannsfeldt) (2011-01-02)|
|Re: language design implications for variant records in a pascal-like bobduff@shell01.TheWorld.com (Robert A Duff) (2011-01-06)|
|Re: language design implications for variant records in a pascal-like cfc@shell01.TheWorld.com (Chris F Clark) (2011-01-14)|
|Re: language design implications for variant records in a pascal-like firstname.lastname@example.org (Peter Canning) (2011-01-18)|
|Treating keywords as identifiers where possible email@example.com (2011-01-19)|
|Re: Treating keywords as identifiers where possible firstname.lastname@example.org (robin) (2011-01-22)|
|From:||email@example.com (Anton Ertl)|
|Date:||Wed, 19 Jan 2011 14:45:28 GMT|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|References:||10-12-040 10-12-043 11-01-005 11-01-009 11-01-027 11-01-057 11-01-086|
|Keywords:||parse, design, LL(1)|
|Posted-Date:||21 Jan 2011 22:06:17 EST|
Peter Canning <firstname.lastname@example.org> writes:
>On 1/14/2011 2:04 PM, Chris F Clark wrote:
>> From a grammar writing point of view, it is not particularly
>> difficult to introduce PL/I style keywords to any LR grammar. The
>> same changes should generally work for LL grammars also. If people
>> are interested I can document them here.
>I'm definitely interested in seeing a description of how to do this (in
>my case for LL grammars).
It's pretty easy for LL(1) grammars: At each position, treat all
keywords as identifiers if they don't occur in the first set. E.g.,
in many languages "IF" occurs only as keyword at the start of a
statement, so in a PL/I-style variant of those languages "IF" could be
treated as identifier everywhere else.
A disadvantage of this approach is that some syntax errors can only be
discovered later. E.g, to pick up the example above, if the semicolon
in front of an IF is missing, a Pascal compiler will notice a syntax
error when it sees the "IF", but not necessarily a compiler for a
PL/I-style language. I don't know how relevant this is in practice.
If only new keywords (for language extensions beyond the original
standard, where new keywords often cause problems) are treated in this
way, this disadvantage is probably small compared to the benefit.
Such a scheme is probably best implemented in the parser (which knows
about the first-sets), but at the interface to the scanner (so the
higher levels don't need to have special treatment of such
M. Anton Ertl
Return to the
Search the comp.compilers archives again.