Re: PERFORM token (was RE: gnubol: Hacks needed to parse COBOL

[RKRayhawk@aol.com]

Concerning the optional number of subclauses on a PERFORM's VARYING clause,
In a message dated 12/3/99 9:55:40 AM EST, wmklein@ix.netcom.com writes:

<< How about 6 levels deep in the '85 Standard - it was 3 in '74.
 
 Bill Klein
   wmklein <at> ix.netcom.com
  >>


Compilers I have seen also impose a limit of just one level for the inline 
perform.  Is this from the standard or vendor specific? Will we need to make 
the subrule distinct for the inline variation in contrast to the out-of-line 
variation?

This also brings up my favorite subject.  What if the code violates the rule, 
by say way to many sub-clauses. Will not the error cause the optimistic rules 
that hard workers have so generously posted to loose control? In the case of 
an inline perform are we not then in great jeopardy of misinterpreting 
subsequent code? This exact location in the parse rules also presents an 
intriguing error possibility.

In compilers I have seen, the END-PERFORM is required on the inline perform, 
but is actually wrong on out-of-line performs. I defy anyone to detect that 
correctly. Since rules have to be concurrently scoped, any out-of-line 
perform can quite possibly be scoped internnaly to an inline perform. If you 
attempt to trap the END-PERFORM on the end of the out-of-line perform where 
it does not belong, then you swallow the outer inline perform's explicit 
scope terminator. Consequently spurious END-PERFORM tokens seem destined to 
fly high into the upper rule hierarchy. 

This is going far into my concurrent rule depiction, I know. But we may need 
a rule for what appear to be stand-alone END-PERFORM 'statements' (which are 
errors of course).

When you look at this problem what you see is that the END-PERFORM not only 
_is_ illegal in out-of-line performs if _must_ be illegal for the language to 
be implementable as currently defined. The whole thing is a bit of a mind 
teaser, but when looked at from the perspective of concurrently running 
scopes you can not have an END-PERFORM on out-of-line performs be optional. 
It is either required, or disallowed; as far as alternative ways to define 
the language. Because of the concurrency of the inline performs you can not 
have it as optional on the 
out-of-line performs.

I think that the END-PERFORM is the only scope terminator that has this 
problem. Although the optional scope terminators for SEARCH and EVALUATE are 
near cousins in the family of monster.

A spurious END-PERFORM will definitely disrupt an inline perform that ought 
to be continuing. In atleast two ways an END-PERFORM can bubble out as an 
apparent naked statement. Sometimes it is just spurious, sometimes it is the 
END-PERFORM that belongs to an inline perform which got disrupted by an 
internal spurious END-PERFORM (that will have been mistaken as the inline 
performs explicit scope terminator).

This is an odd entry point for the suggestion, but generally we need 
productions to catch all manner of END-xyz at some basic statement recurse 
rule. This will be a garbage collection point for refuse from broken 
statements and actual spurious END-xyz tokens. The spurious
END-PERFORM is only a special case.  I think that is the only explicit scope 
terminator that is actually disallowed in some cases.

But trying to set that garbage collector up will be a challenge, because it 
will get intimately ambiguous with all rules that can optionally have an 
explicit scope terminator. Here I must swim upstream of other suggestions and 
say that this should not be done with tokens visible to the grammar. It may 
be necessary to code it as simple the error symbol in competition with all 
statments, and in the action code a rather large case structure to find out 
just what has dropped out as spurious. 

In other word the following probably can not work

super_block :
   add_simple
   {;}
|  add_simple_ENDed
   {;}
|  add_complex
   {;}
|  add_complex_ENDed
   {;}
 .....
|  END-ADD
   {;}
|  END-SUB
   {;}
|  END-PERFORM
   {;}
.../* way to ambiguous */
;



This might work

super_block :
   add_simple
   {;}
|  add_simple_ENDed
   {;}
|  add_complex
   {;}
|  add_complex_ENDed
   {;}
 .....
|  error
   { switch(yylex) {
      case END_ADD: printf "unmatched END-ADD"
      case END_SUB: printf "unmatched END-SUB"
      case END_PERFORM: printf "unmatched END-PERFORM"
     ...
      default:  printf "we is up tha creek"
    };   
    }
 ;

This would need to be more intelligent since error might bubble up in a 
number of ways besides a spurious END-xyz; its the concept that counts.





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