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) |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.