Re: gnubol: procedure types

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

RKRayhawk@aol.com wrote:
> ...
> In the old world, the compiler can use the A-margin to help out. I confess
> that I am a little confused by the examples depicting procedure headers
> floating around in various places, with posted text describing them as
> acceptable. My confusion is that I can not tell if you are saying that stuff
> is valid code now. Is that COBOL-85, or dialectic extension?
> 
I would suggest as follows:

*
     move a to
 b.
>> warning b should be in b-margin. possible missing perion.
>> (user option to turn that warning into a fatal error)
>> 
*
     move a to b. c.
>> warning c should be in a-margin
>> (user option to turn that warning into a fatal error)

In cobol2K, you can't give a warning in either case.

> There is no design or current code to this effect, but discussion seems to
> guess that the preprocessor could be the separator detector.

I wouldn't see the preprocessor doing this, but an early phase of the
compiler proper. Create all the tokens in a linked list and do a simple
pre-scan, adding a few markers to the list to help the main parsers, and
to separate the divisions. I am working on this at the moment.

> ... I am just saying that the gravitation of the collection of code to a
> period-less style, and the float of the procedure  headers (section and
> pragraph names) are phenomena on a collision course.

They should allow something like
paragraph p1.
so people can avoid the potential ambiguity. Just as they should have
put PICs into quotes a long time ago (and required they be in quotes for
new features).

> My idea of the unbalanced parentheses detection is really a safety mechanism.

I don't actually think that unbalanced paremtheses is a big problem. The
can only occur in array refs, reference modifications and expressions.
In all cases unbalanced parentheses will cause the parser to choke very
soon, certainly at the next verb or period at worst. 

If/else/end-if is a variant of the same kind of problem that is often
very bad as RB pointed out - it can span many lines before you you find
an error. Some compilers print out the nesting level as an aid for this.

> We would hear bad noise if we tried to tell the world we would short circuit
> the whole procedure division because of just one paragraph with unbalanced
> parens.

It should only kill the current statement. I can see alot of value in
the kind of prescan as above, but I think the parser should be in the
best position to find the missing () as soon as possible. Error recovery
then becomes

verb error EOS
where EOS is inserted by the prescan above to mark the next verb or
period. Actually it may not be that simple due to nested statements.

You would need to give some more examples to convince me at least that
paretheses is a big issue.

Tim Josling



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