|EBNF definition for RPG? PDackombe@transoft.com (Peter Dackombe) (2000-02-22)|
|Re: EBNF definition for RPG? firstname.lastname@example.org (2000-02-27)|
|Re: EBNF definition for RPG? email@example.com (Charles E. Bortle, Jr.) (2000-02-28)|
|Re: EBNF definition for RPG? firstname.lastname@example.org (2000-02-28)|
|Re: EBNF definition for RPG? email@example.com (Joachim Durchholz) (2000-03-06)|
|Re: EBNF definition for RPG? firstname.lastname@example.org (Jeremy Boden) (2000-03-06)|
|Re: EBNF definition for RPG? email@example.com (Charles E. Bortle, Jr.) (2000-03-06)|
|From:||"Charles E. Bortle, Jr." <firstname.lastname@example.org>|
|Date:||6 Mar 2000 23:38:35 -0500|
|References:||00-02-113 00-02-143 00-02-161 00-03-014|
Charles E. Bortle, Jr. <email@example.com> writes
> >If I were coding the compiler in
> >Pascal I would use variant records, and use the RPG record type as a
> >tag field. Just read a line at a time fromt he source into the
> >record. Now, based on the RPG record type in the tag field, just
> >access the fields directly....no need to scan/parse since the record
> >type automatically parses it for us into appropriate "buckets" :-)
> >Just do semantic processing on a record by record basis since the
> >record automatically pre-parses the input.
Jeremy Boden <firstname.lastname@example.org> wrote in message
> I think you may have particular trouble with the "I" specifications;
> its format varies according to what columns are used. For example it
> could be a multi-line file description, a constant definition, a
> rename of a field, part of a data structure plus quite a few other
> possibilities, some of them machine dependent.
Either I don't know some things about RPG II, or we are speaking about
different versions (It has been 23years since I really did any RPG II,
and that was a class at business college), but AFAIK there is only one
format for an "I" spec in RPG II.
That said, it still might be feasable to use the method I described.
Just declare nested variant records to handle any variant sub-fields.
This, I think, should work; it just means the semantic processing has
to do some of the work of deciding which interpretation to put on the
fields. This may blur the distinction between syntax and semantics,
but that is not an unusual problem in compiler construction. (Or
classify this as part of the "parser" if that cleans up the problem of
where to draw the interface line between the two.)
After all, a fixed format is a fixed format no matter what variations
are applied to the fields, and a formal parser would have to deal with
the same issues, which, it seems to me, would be a more daunting
problem for it than for my proposed reading the "slots" directly. To
quote a line from the movie "Where Eagles Dare", "After all, a hole is
a hole is a hole".
* http://pw2.netcom.com/~cbrtjr/wrdthing.html *
Return to the
Search the comp.compilers archives again.