[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: Hacks needed to parse COBOL
Most of my responses are embedded below. However, the brief of my
suggestions below is that not everything needs to be done by the parser.
Plenty of errors can be reported by a semantic phase traversing the syntax
trees, so the parser won't need infinite look-ahead.
Jonathan
At 06:13 AM 12/2/99 +1000, Tim Josling wrote:
>You are right I think as I suggested. But the amount and ugliness of the
hacks
>needed is very high, and they involve a lot of scanning ahead. I would
like to
>have confirmation that in an expression list, this is the way you are
meant to
>know when an expression ends.
>
>In the draft COBOL 4 standard:
>
>01 a.
>01 b.
> 02 c occurs 5 pic 9.
>
>move 1 to c (a (1)).
>
>What is the correct error message here? "Too many array index expressions
for c"?
>Or "a is not an array and should not have array index expression"?
The definition of 'a' is in error, but I'll discuss the two basic
situations with which I dealt in Wang's implementation. If 'a' is
alphanumeric or usage display, than the left parenthesis that follows it
would be assumed to open a REFMOD, and the error message should flag the
first right paren as coming before the colon. If 'a' is non display
numeric (I didn't have to deal with NATIONAL or BOOLEAN), than the second
left paren is flagged as the begining of the error. Both of these cases
must know from the definition of 'a' that it is not an array, which is
obvious from it being at level 01.
>/* problem 2.
> - after a qualified name, when hitting a "(" you can't tell if it is an
array
>reference or a reference modification
If my memory doesn't mislead me, using the above definitions, I think a
reference may be:
if c(3) of b > 0
rather than
if c of b (3) > 0
so that 'c' is not qualified at the time you are processing the left paren.
I may be mistaken.
>/* problem 4.
> - you need to know that there is a giving coming to know whether a
literal is
>valid after the to
> and whether rounded is permitted
If a literal follows the TO or FROM in the arithmetic statement, can't you
require a subsequent GIVING? That won't require any look-ahead.
>/* problem 11.
> - you need infinite lookahead to determine whether you are expecting a
>procedure name or an expression after 'perform'.
> You could look up the type in the symbol table but what about forward
>references etc.
I think that with a single look-ahead you can determine whether the word
that follows the PERFORM is a reserved word such as UNTIL or VARYING, a
verb, or a user defined word, that must be a procedure name. Then you can
either verify a previously tabulated name and issue errors, or tabulate the
first-used name as a referenced procedure, and leave further error
reporting to the semantic phase.
--------------------------------------------------------------------
J & C Migrations, Pty.
566 Centre Street, Suite 3 http://www.jcmigrations.com
Newton, MA 02458 Fax: +1 (617) 916-5113
USA Tel. +1 (617) 916-5114
--
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.