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

["William M. Klein" <wmklein@ix.netcom.com>]

If you mean (by "same") that it "gets an error" - then I don't believe you
that this gets an error under CURRENT Micro Focus compilers under UNIX (at
least using the '85 Standard option).  That is TOTALLY conforming code and
any compiler that rejects it - has  a BUG.

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 Davyd Ondrejko
> Sent: Tuesday, December 07, 1999 8:07 AM
> To: gnu-cobol@lusars.net
> Subject: Re: PERFORM token (was RE: gnubol: Hacks needed to parse COBOL
>
>
>
> Actually, I just got word from a developer I used to work with that this
> does the same thing under MicroFocus on Unix.
>
>
> Davyd Ondrejko wrote:
> >
> > Here's an interesting situation.
> >
> > >   Bob> In compilers I have seen, the END-PERFORM is required on the
> > >   Bob> inline perform, but is actually wrong on out-of-line
> > >   Bob> performs. I defy anyone to detect that correctly. Since rules
> > >   Bob> have to be concurrently scoped, any out-of-line perform can
> > >   Bob> quite possibly be scoped internnaly to an inline perform. If
> > >   Bob> you attempt to trap the END-PERFORM on the end of the
> > >   Bob> out-of-line perform where it does not belong, then you swallow
> > >   Bob> the outer inline perform's explicit scope
> > >   Bob> terminator. Consequently spurious END-PERFORM tokens seem
> > >   Bob> destined to fly high into the upper rule hierarchy.
> > >
> > > OK, I get the idea, but I still can't share your sense of dread over
> > > it.  The END-PERFORM is no more a part of the syntax of an
> > > out-of-line PERFORM than END-EVALUATE is.  Sure, a containing in-line
> > > PERFORM will be terminated.  Then we'll continue to parse some more
> > > statements that should have been in the loop or whatever.
> > > Eventually, we'll get to an END-PERFORM that can't be accepted and
> > > we'll diagnose it.  In the unlikely case that the programmer has
> > > applied an END-PERFORM to his out-of-line PERFORM, and omitted the
> > > one for the containing in-line PERFORM, he has made a programming
> > > error, but he has written a legitimate COBOL program.
> >
> > MOVE 0 TO Q.
> > MOVE 13 TO VARIABLE.
> > IF VARIABLE > 3
> >     PERFORM UNTIL Q > 10
> >         ADD 1 TO Q
> >         PERFORM THIS-PARAGRAPH THRU THIS-PARAGRAPH-EXIT
> >     END-PERFORM
> >     DISPLAY "Q IS NOW = ", Q
> > END-IF.
> >
> > In one compiler I've come across (ICHOST under UNIX), depending on the
> > settings, this will generate a warning or an error.  (Not sure, don't
> > have access to it at this point.)  The END-PERFORM actually associates
> > with the out-of-line PERFORM and leaves the in-line PERFORM without any
> > termination.  If it generates code, then the DISPLAY is executed 11
> > times.
> >
> > --
> > David R. Ondrejko - EDI/Referral - Safelite Glass Co.
> >  Mathematician by training - Programmer by trade - Philosopher by nature
> >  Genius by genetics - Atheist by conviction - Hedonist by desire!
>
>
> --
> David R. Ondrejko - EDI/Referral - Safelite Glass Co.
>  Mathematician by training - Programmer by trade - Philosopher by nature
>  Genius by genetics - Atheist by conviction - Hedonist by desire!
>
> --
> 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.