(YACC&LEX) PL/I Grammar 
Author Message
 (YACC&LEX) PL/I Grammar

Quote:

> >(YACC&LEX) Does anyone have or know of a source of a yacc&lex
> >grammar for PL1?

> I wonder how hard it would be to do.

> Note that PL/I doesn't have any reserved words, so it will be harder
> to recognize keywords.  

> IF IF=THEN THEN THEN=ELSE; ELSE IF=THEN;

It's not so bad as it first appears.
In parsing the expression after the first "IF",
it is unnecessary to first look up keywords.
That is, it is necessary only to look up the identifier and built-in
function lists.  The next time a search of the keywords is needed
is after that expression, when the isolated THEN is processed.
The expression THEN=ELSE is similarly processed as an expression,
which does not require consultation of keywords.
And so on for ELSE amd the expression IF=THEN.
Quote:
> -- glen



Tue, 03 Aug 2004 12:32:43 GMT  
 (YACC&LEX) PL/I Grammar

Quote:

writes:

> > >(YACC&LEX) Does anyone have or know of a source of a yacc&lex
> > >grammar for PL1?

> > I wonder how hard it would be to do.

> > Note that PL/I doesn't have any reserved words, so it will be harder
> > to recognize keywords.

> > IF IF=THEN THEN THEN=ELSE; ELSE IF=THEN;

> It's not so bad as it first appears.
> In parsing the expression after the first "IF",
> it is unnecessary to first look up keywords.
> That is, it is necessary only to look up the identifier and built-in
> function lists.  The next time a search of the keywords is needed
> is after that expression, when the isolated THEN is processed.
> The expression THEN=ELSE is similarly processed as an expression,
> which does not require consultation of keywords.
> And so on for ELSE amd the expression IF=THEN.

This last been seems wrong.  How do you know the
phrase  ; ELSE IF ...
isn't the start of an IF statement and not an assignment?

Are you speaking from experience, having actually implemented such a parser,
that has been tested seriously?

Our experience building parsers in general is this kind of stuff
is always a pain, and our parsing technology is good
at handling arbitrary lookaheads.

FWIW, we have a draft PL/1 parser.  I emphasize draft;
I'm sure it doesn't handle many things right,
and then you have the following issues of
handling preprocessor directives and name/type resolution.
(It does handle the above case just fine).

It is *not* easy to build a practical, working PL/1 parser.

--
Ira D. Baxter, Ph.D. CTO Semantic Designs, Inc.
http://www.semdesigns.com



Wed, 04 Aug 2004 00:57:47 GMT  
 (YACC&LEX) PL/I Grammar

Quote:


> > >(YACC&LEX) Does anyone have or know of a source of a yacc&lex
> > >grammar for PL1?

> > I wonder how hard it would be to do.

> > Note that PL/I doesn't have any reserved words, so it will be harder
> > to recognize keywords.

> > IF IF=THEN THEN THEN=ELSE; ELSE IF=THEN;

> It's not so bad as it first appears.

It's more complicated than that.

Consider these examples:

if (exp1) then ...

if (exp1) = exp2 ;

if (exp1) = exp2 then ...

Since both exp1 and exp2 may consist of an arbitrary number of tokens, the traditional methods of
organizing shift reduce parsers have to be abandoned unless we are willing to somehow allow an
arbitrary amount of look ahead.

Also, what, if anything, an identifier has been declared to be cannot, in general, be known with
certainty until the end of the outermost block has been seen.

The designers of PL/I opted to give the programmer a language free of arbitrary restrictions
introduced solely to make life easy for the compiler writers.  That doesn't mean they purposely made
life difficult for compiler writers.  The richness and generality of the language saw to that.

In contrast, in designing Pascal, Niklaus Wirth left out anything that presented an implementation
challenge, then justified the omission by saying, in essence, that for example, exponentiation is
complicated and difficult to implement correctly thus we should leave it for the programmer.

Sadly, those who added extensions to the more recent versions of PL/I such as unions and enumerated
types cut their teeth on Pascal and C and have snuck in unnecessary reserved words and ordering
restrictions by the back door.

To return to the point, correctly parsing the entire language to yield a parse tree that facilitates
translation to a semantically correct object program is exceedingly difficult.



Wed, 04 Aug 2004 09:25:33 GMT  
 (YACC&LEX) PL/I Grammar
Look ahead.  If you find ELSE IF= or ELSE IF, (or various other similar
things) it's an assignment, otherwise it's a nested IF.  The problem is
that the number of tokens to look-ahead can be large.  Look at the
following article (may even be available online fromn the ACM):

 Abrahams, Paul W.
 "The CIMS PL/I Compiler"
 Proceedings of the SIGPLAN Symposium on Compiler Construction
 Denver, CO; Aug 6-10, 1979; 107-116.

Quote:


> > > Note that PL/I doesn't have any reserved words, so it will be harder
> > > to recognize keywords.

> > > IF IF=THEN THEN THEN=ELSE; ELSE IF=THEN;

> > It's not so bad as it first appears.
> > In parsing the expression after the first "IF",
> > it is unnecessary to first look up keywords.
> > That is, it is necessary only to look up the identifier and built-in
> > function lists.  The next time a search of the keywords is needed
> > is after that expression, when the isolated THEN is processed.
> > The expression THEN=ELSE is similarly processed as an expression,
> > which does not require consultation of keywords.
> > And so on for ELSE amd the expression IF=THEN.

> This last been seems wrong.  How do you know the
> phrase  ; ELSE IF ...
> isn't the start of an IF statement and not an assignment?

> Are you speaking from experience, having actually implemented such a parser,
> that has been tested seriously?



Wed, 04 Aug 2004 22:14:39 GMT  
 (YACC&LEX) PL/I Grammar

Date: Fri, 15 Feb 2002 17:25:33 -0800
.

||
|| > > >(YACC&LEX) Does anyone have or know of a source of a yacc&lex
|| > > >grammar for PL1?
||
|| > > I wonder how hard it would be to do.
||
|| > > Note that PL/I doesn't have any reserved words, so it will be harder
|| > > to recognize keywords.
||
|| > > IF IF=THEN THEN THEN=ELSE; ELSE IF=THEN;
.
|| > It's not so bad as it first appears.
.
|| It's more complicated than that.
.
|| Consider these examples:
.
|| if (exp1) then ...
.
The expression terminates with "then", and no special effort is required to
recognize "then" as a keyword.  
.
|| if (exp1) = exp2 ;
.
The expression terminates with the assignment '='.  There is no difficulty
in parsing this when there is no array "if" declared.
If there is an array 'if', parsing must continue until the semicolon
has been encountered before a decision can be taken on whether it is
an IF statement of an assigment.
.
The above two instances have their counterparts in fortran, which
doesn't have keywords either.
.
|| if (exp1) = exp2 then ...
.
See above.
.
This is IF ( <expression> ) = <expression> THEN
.
|| Since both exp1 and exp2 may consist of an arbitrary number of tokens,
!! the traditional methods of
|| organizing shift reduce parsers have to be abandoned unless we are
!! willing to somehow allow an
|| arbitrary amount of look ahead.
.
exp1 and exp2 can be fully parsed, and expression trees
produced without look-ahead.
.
|| Also, what, if anything, an identifier has been declared to be cannot,
|| in general, be known with
|| certainty until the end of the outermost block has been seen.
.
This is always the case.  Declarations are collected
in a pre-pass.
.
|| The designers of PL/I opted to give the programmer a language free of
!! arbitrary restrictions
|| introduced solely to make life easy for the compiler writers.
!! That doesn't mean they purposely made
|| life difficult for compiler writers.  The richness and generality
!! of the language saw to that.
.
|| In contrast, in designing Pascal, Niklaus Wirth left out anything
!! that presented an implementation
|| challenge, then justified the omission by saying, in essence,
!! that for example, exponentiation is
|| complicated and difficult to implement correctly thus we should
!! leave it for the programmer.
.
And quite a few other things, like string handling, and proper I/O
(including the defective EOLN and EOF), array bounds checking etc.
.
Of all the questions that were put to me about Pascal, "how do you raise
to a power?" was the most frequent.
.
|| Sadly, those who added extensions to the more recent versions
!! of PL/I such as unions and enumerated
|| types cut their teeth on Pascal and C and have snuck in
!! unnecessary reserved words
.
such as?
.
!! and ordering restrictions by the back door.
.
Such as?
.
|| To return to the point, correctly parsing the entire language
!! to yield a parse tree that facilitates
|| translation to a semantically correct object program is
!! exceedingly difficult.
.
To return to the point, it's not as bad as it first appears.
.
And it's a whole lot better than say, COBOL, with some 300 reserved
words.


Sat, 07 Aug 2004 08:25:34 GMT  
 (YACC&LEX) PL/I Grammar

Quote:


> Date: Fri, 15 Feb 2002 17:25:33 -0800

>  .<snip>

A comprehensive discussion of these topics is mentioned in:
http://groups.google.de/groups?q=vienna+definition+language+bauer&hl=...

It contains references to various articles concerning PL/1 and other
languages.

Arthur Fichtl



Mon, 23 Aug 2004 21:38:20 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. (YACC&LEX) PL/1 Grammar

2. Looking for fortan yacc grammar & lex parser

3. lex/yacc grammar available?

4. lex/yacc grammar for REXX

5. lex/yacc grammar for vrml2.0

6. Verilog lex/yacc grammar

7. Grammar Yacc/Lex for ADA95

8. lex and yacc grammar for VHDL '93 ???

9. Free unbugged lex/yacc based grammar for VHDL

10. lex/yacc grammar update

11. Ada grammar for yacc/lex

12. Yacc/lex grammar for Ada

 

 
Powered by phpBB® Forum Software