Re: Parsing nested statements: was Re: gnubol: subsets

[Michael McKernan <mck@tivoli.mv.com>]

>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Wed, 24 Nov 1999 22:56:32 EST

  Bob> Conditional Encounters of The Implicit Kind

  Bob> At
  Bob> http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/IGYLR201/6%2e1%2e7
%2e5?S
  Bob> HELF=

  Bob> you can find

  Bob> "6.1.7.5 Implicit Scope Terminators

  Bob> "At the end of any sentence, an IMPLICIT SCOPE TERMINATOR is a
  Bob> separator period that terminates the scope of all previous
  Bob> statements not yet terminated.

  Bob> "An unterminated conditional statement cannot be contained by
  Bob> another statement. However, a scope terminator will be assumed
  Bob> just prior to the next phrase of the containing statement.

  Bob> "Note: Except for nesting conditional statements within IF
  Bob> statements, nested statements must be imperative statements,
  Bob> and must follow the rules for imperative statements. You
  Bob> should not nest conditional statements. "

  Bob> So look real careful at the sentence: "However, a scope
  Bob> terminator will be assumed just prior to the next phrase of
  Bob> the containing statement. "

A nice weasel-worded statement, this.  I think it tells me that Big
Blue is doing exactly what I have been advocating, as I would have
expected them to.  

It looks to me like they're saying "you're not allowed to write a
conditional statement within another statement, but if you do, we're
going to assume that it's been terminated."  

In other words they're going to parse the inner statement as if they
expect to find a terminator, but when they get to something that does
not continue or legitimately terminate the inner statement, they'll
consider the inner statement successfully parsed and try to continue
the parse of the containing statement with the current token.  If
they are successful, you have the scope terminator "assumed just
prior to the next phrase of the containing statement" and if not they
get to bury the whole thing with a different error.  Voila!

That is, of course, exactly what I think we should do.

  Bob> If you are not ready for it, it will do a number on your mind.
  Bob> If you have already seen the light, it is obvious.  The
  Bob> conditional clauses have no ordinality.  Simple imperatives
  Bob> can be expressed in the interior without their own explicit
  Bob> scope terminator as long as they don't hope to have a
  Bob> conditional clause or so of their own that needs to be scoped
  Bob> to the interior. That flexibility is accomplished by an
  Bob> 'assumed' scope terminator just prior to the conditional
  Bob> clause that belongs out at the outer arithmetic
  Bob> statement. Scouts honor!

Let's apply Occam's razor, here.  My explanation is simpler, does not
require heroic parsing technology and minimizes astonishment.  Yours
seems to be an ingeniously constructed circles within circles
argument, admirably complete in every particular, but not necessarily
grounded in reality.  Is there any empirical evidence for either
side? 

  Bob> Yet such an 'assumption' can not be committed until lookahead
  Bob> confirms that there is no explicit scope terminator on the
  Bob> interior, the absence or presence of which might be miles
  Bob> away. A bit of a Rubic's cude ain't it?!

IBM got sucked in on multiple and nested occurs depending some years
ago, producing probably the only legitimate implementation before the
committee admitted it was a bad idea and retracted virtually the
whole thing.  The implementation was absolutely horrible but probably
as good as it could possibly have been.  There are some things that
can't be implemented in any reasonable manner.  I don't believe
they're going to let j4 suck them in again.

  Bob> This quote is not from the standard but from a field manual
  Bob> that depicts the code base we need to consider. All material
  Bob> at the site is proprietary.

And a nice bit of verbiage it is.  You can make it mean whatever you
want. 

  Bob> More than any other GNU project, it is the code base that
  Bob> counts for this effort. The standard is the guide but we must
  Bob> remain committed to the owners of the code base.

  Bob> Legacy code is real even if the ink is still wet. Crossing
  Bob> platforms is what the industry is turning into. COBOL is front
  Bob> and center. And in the center is quite possibly a mix of
  Bob> ideas.

No argument on any of these points.

  Bob> Best Wishes Bob Rayhawk RKRayhawk@aol.com

  Bob> P.S. When we are really ready we will talk about packed
  Bob> numbers, and convergence. That will be fun.




  Bob> -- This message was sent through the gnu-cobol mailing list.
  Bob> To remove yourself from this mailing list, send a message to
  Bob> majordomo@lusars.net with the words "unsubscribe gnu-cobol" in
  Bob> the message body.  For more information on the GNU COBOL
  Bob> 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.