Re: Treating keywords as identifiers where possible

"robin" <robin51@dodo.com.au>
Sat, 22 Jan 2011 16:40:25 +1100

          From comp.compilers

Related articles
[2 earlier articles]
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 gah@ugcs.caltech.edu (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 9cn6w6402@sneakemail.com (Peter Canning) (2011-01-18)
Treating keywords as identifiers where possible anton@mips.complang.tuwien.ac.at (2011-01-19)
Re: Treating keywords as identifiers where possible robin51@dodo.com.au (robin) (2011-01-22)
| List of all articles for this month |
From: "robin" <robin51@dodo.com.au>
Newsgroups: comp.compilers
Date: Sat, 22 Jan 2011 16:40:25 +1100
Organization: Compilers Central
References: 10-12-040 10-12-043 11-01-005 11-01-009 11-01-027 11-01-057 11-01-086 11-01-091
Keywords: syntax, parse
Posted-Date: 22 Jan 2011 20:57:54 EST

From: "Anton Ertl" <anton@mips.complang.tuwien.ac.at>
Sent: Thursday, 20 January 2011 1:45 AM


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


A compiler for a PL/I style language will pick that up as a syntax
error (i.e., a missing semicolon). IBM's PL/I will probably advise
that it has assumed a semicolon and continued normally, treating the
omission as a trivial error.


Such an omission is detected because there would otherwise appear to be
a missing operator or some such before the "IF".


    See compiler output below:--
______________________


5639-D65 IBM(R) VisualAge(TM) PL/I for Windows(R) V2.R1.00 2011.01.22 16:31:10 Page 3
  Line.File


        3.1 test: procedure options (main);
        4.1 declare (a, b) fixed;


        6.1 a = b
        7.1 if a > b then b = a;


        9.1 end test;


5639-D65 IBM(R) VisualAge(TM) PL/I for Windows(R) V2.R1.00 2011.01.22 16:31:10 Page 4


Compiler Messages


Message Line.File Message Description


IBM1122I W 7.1 Missing ; assumed before IF.



Post a followup to this message

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