Re: gnubol: distinguishing data refs and conditional refs

[Tim Josling <tej@melbpc.org.au>]

Bob,
I must admit that at first these ideas seemed way out but they
are making more sense now. 

I think though it is a good idea to have separate grammars for
the data and procedure. It is also probably a good idea to
delimit the statements before the main parser sees them
(statements are nested of course) to make its life easier and to
improve error recovery.

There is definitely a need to feed some symbol table information
into the parser (e.g. the conditional expression a = b and not c
- c could be an 88 level or an actual data item).

My thinking though was with those caveats the parser should
recognize the structures correctly - with whatever help it needs.
Then you validate by hand.

For example:

move paragraph1 to file2.

Should the error message be: 

"paragraph illegal as sending operand" plus "file illegal as
receiving operand" or

"test1.cob:137 syntax error at paragraph1".

I tend to think the syntax error could be very confusing,
although it could be improved with "expecting data name". Once
you have a syntax error you basically lose the statement and you
can't do any more error checking (in the example above these is
no visibility to the erroneous file2 as receiving item).

I need to do some more experimenting on this. I'm sure some
things will surprise us.

The symbol table usage is more complex in cobol because of the
complex scope rules (nested programs, global variables) but also
because of the a of b of c type of construct. You may have to
look ahead up to 100 symbols or so. Also the rule that it is
perfectly legal to have duplicate data names as long as you don't
reference them. e.g.:

01 data1 pic x.
01 data1 pic x.

That's fine, but don't try 'display data1.'.

(I got into the habit of putting 1 at the end of data names
because I got sick of hitting cobol reserved words). Then IBM
invented "skip1", oh well.

Bob also mentioned that backtracking is slow. According to the
BTYACC and pccts doco they only backtrack when needed and this is
said to be only a small % of the time. So, they claim, it is not
a problem. Does anyone have any data on this? Normally the parser
only takes up a small % of the compiler's time.

At the moment I can put 20-25 hours a week into this, but then
again I might get sick of it tomorrow and not write another line
of code. My long term project is a wav2midi program. Compared to
that, cobol is a piece of cake.

Tim Josling

RKRayhawk@aol.com wrote:
>...

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