Re: gnubol: procedure types

[Randall Bart <Barticus@att.net>]

At 10:36 AM 11/3/99 , RKRayhawk@aol.com wrote:
>In a world with A-Margin and B-Margin conventions, paragraph/section
>separators will be fairly easy to find (by the preprocessor). But in the
>future world that we are supposed to have our eye on, a label is going to be
>a little harder to find within a parenthetically unbalance source file. But
>maybe we will let that bridge burn us when we attempt the crossing.

Paragraph/section headers are easy to find in a margin-less world.  A 
header comes right after a separator period.  It can be the period of the 
PROCEDURE DIVISION header, the DECLARATIVES header the END DECLARATIVES 
header, a section header, a USE statement or an executable statement, but 
one way or another there is a period.  If you're in the procedure 
divisions, if the COBOL word which follows a period isn't a reserved word, 
it's a procedure name declaration (or an error).

This leads to misidentified errors like this:

     ADD 1 TO A,
              B,
              C.
              D.

D is parsed as a paragraph name declaration.  Usually, the compiler flags 
every reference to D but this one, saying the name needs qualification.  In 
the unlikely event there are no other references to D this gets a clean 
compile.  Note that in COBOL-20XX a paragraph name needn't start a line, eg,

     ADD 1 TO A, B, C. D.

is also a declaration of paragraph D.  Most compilers give a warning in 
this instance.

>Ideally, we would want to comprehend the unbalanced code at a level below the
>procedure level (that is within the paragraph). But there is already a really
>large amount of code bereft of end of statement periods, and that will just
>be increasing in the future. So it seems challenging to delimit the
>unbalanced code at some level below procedure, ... atleast prior to parsing.

I think you are confusing the period in COBOL for the semicolon in C and 
the other Algoloids.  In other languages a semicolon can occur deep within 
a nested statement, but in COBOL a period ends every level of nesting 
except paragraph, section, and program.  (There is an exception.  Tom, care 
to jump in with the exception and explain why it's not relevant?)

Similarly, a verb ends an expression but it does not end nested 
statements.  Many parsers implement ELSE, END-IF, WHEN, etc as verbs, and 
then match them to their antecedents later.  Having the grammar match IF 
with ELSE and END-IF would be nice, but it's not necessary.  Either way, 
it's work.

There are some gotchas in match scope terminators to their 
antecedents.  Consider the following:

MULTIPLY A BY B
     ON SIZE ERROR   ADD 1 TO ERROR-COUNT
END-MULTIPLY
DIVIDE A BY B
     ON SIZE ERROR   ADD 1 TO ERROR-COUNT
END-DIVIDE
ADD A TO B
     ON SIZE ERROR   ADD 1 TO ERROR-COUNT
END-ADD
SUBTRACT A FROM B
     ON SIZE ERROR   ADD 1 TO ERROR-COUNT
END-SUBTRACT

The indentation matches what a typical programmer would expect, but in fact 
the SUBTRACT statement is still within the SIZE ERROR phrase of the ADD 
statement.  The END-ADD pairs with ADD 1 TO ERROR-COUNT.

>(A middle ground here could be, to isolate at a level lower than procedures,
>if the code _does_ have end-of-statement periods. That could be the next
>compiler.)

Periods don't end statements, they end sentences.  All programs have 
them.  A statement is ended by a subsequent verb (counting period as a verb).

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