Re: [GNU-COBOL] GNUBOL refmod, OFIN and transparencies

[Randall Bart <Barticus@att.net>]

At 10:33 AM 10/30/99 , RKRayhawk@aol.com wrote:

>  refmod
>     : OPAREN integer1 COLON integer2 CPAREN
>     ;
>
>integer2 is not required on compilers I have used.

Integer2 is optional in X3.23-1985 and the draft.

>Also, once upon a time it was legal to have within a single program
>paragraphs with identical names in different SECTIONS.  To PERFORM a
>paragraph like that required syntax such as PERFORM AMBI-GRAPH OF
>SECT-WHICHEVER. Does this still apply in COBOL-85?

Yes.  Why would they get rid of it?  The important point is that the 
ambiguously named paragraph may be referenced as AMBI-GRAPH OF 
SECT-WHICHEVER from anywhere in the procedure division and also may be 
referenced as just AMBI-GRAPH from within SECT-WHICHEVER, thus each section 
is a distinct lexical environment.

>If this ambiguous paragraph name issue applies
>  then we may want distinct 'ident', 'PROG_NAME' and 'qualifier' for 
> datanames
>as opposed to procedure names. But still the OF/IN token could be a source of
>ambiguity. Let's ferret it out as early as possible in our work

You don't need a separate production for <para> OF/IN <sect>, but it might 
be preferable.  They don't show up in the same context, and procedure name 
qualification isn't recursive while data-name, condition-name, and 
index-name are.

>As an aside, I would recommend generally that we turn the OF|IN distinction
>into a transparency to reduce parser internal table size. That is, if the
>lexer sees OF, it returns OFIN, if it sees IN it returns OFIN. A similar
>recommendation seems appropriate for IS|ARE and a few other wonderments like
>ZERO, ZEROES and ZEROS, as well as PIC|PICTURE.

IN and OF are synonymous in procedure division code, but not in the 
environment and data divisions there are spots where IN is allowed but OF 
isn't.  I don't think there's a case which allows OF but not IN since the 
abolition of VALUE OF.

Similarly, there are several spots which allow IS but not ARE.  Combining 
them in pre-parsing wouldn't stop any valid compilation but would make it 
impossible to issue extension warnings for code that ought to be invalid, 
eg PIC ARE XXXX would compile without a warning.  Is this an issue?

The true synonyms are PIC|PICTURE, THROUGH|THRU, COMP|COMPUTATIONAL, 
CORR|CORRESPONDING, SYNC|SYNCHRONIZED, HIGH-VALUE|HIGH-VALUES, 
LOW-VALUE|LOW-VALUES, SPACE|SPACES, QUOTE|QUOTES, and 
ZERO|ZEROS|ZEROES.  There are some others that may be perfect synonyms, but 
I haven't looked carefully or exception:  AREA|AREAS, 
COL|COLS|COLUMN|COLUMNS, LIMIT|LIMITS, LINE|LINES.  There are some I know 
are wrong, but ought to work except for flagging the extensions:  IS|ARE, 
IN|OF, RECORD|RECORDS, and VALUE|VALUES.

>More radically, COMMA should probably be invisible to the procedure division
>parser (they are needed in literals).

According to the standard, the separator tokens comma, semicolon, and 
period are only separator tokens if they are followed by white space.  Thus 
theoretically no special scanning logic is needed for comma in PIC (parens 
are another matter).  However, this means that A(B,C) is invalid because 
the comma is not a separator comma.  This aggravates programmers, so most 
compilers allow this as an extension.  If A(B,C) is legal in the procedure 
division then it also should be allowed in the report section (subscripts 
in the report section are very rare, but they exist).

But once comma and semicolon are recognized as tokens they should be 
ignored.  Also, THEN is universally ignored by some compilers (which 
humorously allows LESS THEN and GREATER THEN).

>  That almost applies to the data
>division, but you would have to make it context sensitive for PIC clauses and
>literals. I am not actually straying off the subject here. The 'subscript(s)'
>productions, ...

Literals are handled the same in COBOL as other languages.  But you are 
right that following PIC, parentheses must have special handling, and comma 
ought to.

>subscript
>     : (ident ( qualifier )* { (PLUS|MINUS) integer } | integer)
>
>And one further note, a question really.  Do you define 'integer' as positive
>or unsigned? It cannot be unary negative.

According to the draft, p 32, 5.1.3 Operands: "The term 'integer' in a 
general format refers to an unsigned non-zero integer numeric literal."

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