[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PERFORM token (was RE: gnubol: Hacks needed to parse COBOL
(I think this is the two questions that I can answer)
1) The "after" variation of VARYING (i.e. handling of more than one level of
VARYING) is explicitly DIS-allowed for inline PERFORMs. Most (but not all)
compilers enforce this strictly. FYI, this rule/restriction will be removed
in the next Revision, so it would be a "nice" extension to allow it.
2) END-PERFORM is indeed unique in that it is REQUIRED for inline PERFORMs
and PROHIBITED for out-of-line PERFORMs. Again, Micro Focus has a documented
extension (also flagged) that allows it to be omitted for SOME inline
performs, but this is NOT something that I would suggest doing. (No-one that
I know of allows it for an out-of-line PERFORM.)
Bill Klein
wmklein <at> ix.netcom.com
> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of
> RKRayhawk@aol.com
> Sent: Friday, December 03, 1999 10:41 AM
> To: gnu-cobol@lusars.net
> Subject: Re: PERFORM token (was RE: gnubol: Hacks needed to parse COBOL
>
>
> 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.
--
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.