[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnubol: Parse This



At 03:28 PM 11/13/99 , Tim Josling wrote:
>At present the only case for backtracking I have run across is the
>reference modification/array ambiguity. I don't see that forcing an
>explosion. Refmods are only allowed in certain circumstances so you
>could use a less powerful form of identifier in most cases that
>eliminates the suspense.

Actually subscripting can be distinguished from reference modification 
based on symbol table information (as Bob has mentioned).  If a field can 
be subscripted it _must_ be subscripted, except in a SEARCH statement, 
where it can't be reference modified either.

A real problem is distinguishing reference modification from an arithmetic 
expression.  Numeric display fields can be reference modified and used as 
numerics.  Commas are always optional, so subscripts and function arguments 
aren't separated by commas, they are separated where the next token isn't 
part of a valid expression.

     FUNCTION MIN (A (B:C) D)

Even if we know A isn't subscripted, we don't know whether B is part of the 
first or second parameter until the colon.

Reference modification is quite rare in this circumstance.  It should be 
acceptable for the parser to assume the previous parameter (or subscript) 
has ended, and then backtrack when the colon is encountered.  Fortunately, 
the colon has no other use in Cobol (the 20XX draft allows colon as a PIC 
insertion character), so it's always parseable one way or another.  As 
usual, B is an expression, so it may be infinitely many tokens.

At 02:19 PM 11/13/99 , Tim Josling wrote:

>RKRayhawk@aol.com wrote:
> > ... good stuff, plus
> > Perhaps, well, we should probably get a handle on the exact number. I think
> > that the requirement that level numbers basically be 01 through 49 brings
> > that down some (we can have 01s within FDs/SDs, and an 88 is actually under
> > an element in the sense that syntactically
> >   cond-88-name OF data-49-name
> > is valid. So 50 or 60.
>
>Plus the of/in of course, making around 100.

A condition-name may be qualified by 49 data-names and a file-name, 
cd-name, or report-name.  Including IN/OF that would be 101 tokens (not 
counting subscripting).  Pragmatically, three levels of qualification is 
quite a lot.

In my opinion the compiler should crash if it runs out of memory, or a
resource like a file does not exist. No other limitations.

IMNSHO, a compiler should only "crash" due to system problems beyond it's 
control (corrupted code file, other program corrupting memory, etc).  For 
anything else, the compiler should gracefully end with a descriptive error 
message, eg, "Fatal error:  Reserved word file is missing".

>IBM's
>mainframe compiler has an undocumented limit on the number of forward
>procedure references. These limits can cost people a lot of money.

How big is the limit, and is the error message informative or 
cryptic?  Most procedure references are forward, and there are some huge 
programs.  I have worked on one Cobol program over 63,000 lines, and others 
over 50,000, and I know there are some even bigger.  The parser should not 
fail on a program of 1,000,000 tokens, though the back end may be limited 
by the limits of the target platform.

--
RB |\  Randall Bart
aa |/  Barticus@usa.net 818-985-3259 Barticus@att.net
nr |\  8321 Burnet Av #1, North Hills, CA 91343
dt ||\
a   |/ Y2K website:    http://users.aol.com/PanicYr00
l   |\
l   |/ DOT-HS-808-065     I Love You    MS^7=6/28/107


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.