Re: gnubol: subsets

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

>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Sun, 21 Nov 1999 05:28:50 EST

  Bob> In a message dated 11/20/99 10:26:11 PM EST, mck@tivoli.mv.com
  Bob> writes, sketching a pair of ADD statements, first :

<< 
 add_stmt
    : ADD 
      ( CORR identifier TO identifier { ROUNDED }
      |  ( identifier | numeric )+
         ( giving_phrase    
         ! TO ( identifier | numeric ) giving_phrase
         | TO ( identifier { ROUNDED } )+
         )
      )
      { size_err }
      { END_ADD }
    ;
  >>

  Bob> And then one that does the END-ADD a little differently. And
  Bob> yes in my post I am saying that you will need alternates of
  Bob> the complexity you chart. However, as a first approximation,
  Bob> the basic add statement that is to be folded into the rest of
  Bob> the grammar would not have any END-ADD at all. That is what
  Bob> makes it conditional when it has the conditional ON SIZE
  Bob> ERROR. (That is, the absence of the END-ADD prevents it from
  Bob> transforming into an imperative).

  Bob> As a first approximation, the alternate, the imperative ADD,
  Bob> has a non optional END-ADD. They can not both have END-ADDs or
  Bob> they are ambiguous.

No, they are not ambiguous but I, admittedly, have not tried the
convince the parser generator of this.  Parser generators are not
ideal reasoning machines; they do have their limitations.  Even my
original rule, aside from the considerations of the current
discussion, reports an ambiguity because everything that terminates
the SIZE phrase is optional.  The ambiguity is harmless because the
parse ends whenever it encounters a token which is not a verb at the
beginning of the iterative (statement)+ rule.  I could use a
predicate to eliminate the ambiguity, but the resulting parser would
be equivalent, except that it would execute a useless test for the
predicate. 

  Bob> On _second_ approximation, it is worse. You also need rules
  Bob> for the unconditional ADD, (that is one with no optional ON
  Bob> SIZE ERROR. The two varieties of that must be available to the
  Bob> grammar, one with END-ADD and one with not: as long as there
  Bob> is no chance of the optional ON SIZE ERROR, then each variety
  Bob> is imperative. ((It might take a while to see that at first,
  Bob> but to get the simple one into the imperative category, I am
  Bob> sure that atleast a third rule is needed.)) So when you said
  Bob> of the second rule "You're asking me to add a rule Similar to
  Bob> the following for every verb that might include a conditional
  Bob> phrase" To be honest I think it is perhaps four rules not just
  Bob> an unhappy two.

Two are sufficient IFF the imperative_add_stmt is acceptable to the
generator.  These are the cases.

    ADD a TO b			   imperative
    ADD a TO b END-ADD		   imperative
    ADD a TO b SIZE ...		   conditional
    ADD a TO b SIZE ... END-ADD	   imperative

This fragment from the imperative_add_stmt 	  

    (  size_err END_ADD 
    |  { END_ADD }
    )

says that if the SIZE phrase is present, END-ADD is required,
otherwise END-ADD may or may not be present.  The first alternative
accepts the fourth case, the second cases one and two.

  Bob> But from the point of view of my interest in error trapping,
  Bob> there is yet more.  Suppose that we get all those rules in
  Bob> there, or some fewer number that does the job.  So now we are
  Bob> set to go. And presto sombody puts an inner conditional
  Bob> arithmetic statement without an explicit scope terminator
  Bob> hanging this onto the conditional branch of an outter
  Bob> arithmetic statement.

  Bob> In the absence of specialized rules, the inner arithmetic
  Bob> statement ends and reduces and the ON SIZE ERROR attempts to
  Bob> shift onto (glue onto) the outter arithmetic statement. If we
  Bob> do that well we are lucky. It might, in 50%, of the cases look
  Bob> like a duplicate. But if we were smart, and here too we need
  Bob> an inspiration, it would be nice to warn at the inner
  Bob> arithmetic statment; regardless of whether the ON SIZE ERROR
  Bob> eventually glues or faults as a duplicate at the higher
  Bob> level. I cannot conceive of a way to do that unless we infact
  Bob> do trace forward with (the dreaded) attributed grammar
  Bob> techniques.  But really the compiler user needs to hear from
  Bob> us if conditional clauses are associating left straight
  Bob> through otherwise applicable verbs as though they were
  Bob> transparent. The problem is broader than the arithmetic
  Bob> statements.

That isn't what happens.  In the original sample

     ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD

the END-ADD cannot possibly bind to the SUBTRACT so it's an error or
it belongs to the ADD.  The standard says it's an error, but
accepting it and assigning it (what appears to be) its intended
semantics is not a problem.  I'll come back to my original point,
that these rules are not here to help the user diagnose his program,
but to retain the validity of existing code.  If the above sample had
been

     ADD ... SIZE ... ADD ... SIZE ... END-ADD

the END-ADD binds to the inner ADD, regardless of misleading
indentation, and NO ERROR EXISTS!  The rules are being selectively
helpful at best.

Also consider this variant

     ADD ... SIZE ... SUBTRACT ... SIZE ... PERIOD

which appears to be as invalid as the first, but trashes the law of
least astonishment, since the PERIOD has traditionally, legitimately,
terminated anything that's going on.

  Bob> But yes, I think there are at least two, sometimes four in
  Bob> these burdensome sets.

  Bob> There is a variation of this that is even more strange, but I
  Bob> don't think it is any different to code. A conditiional branch
  Bob> can have, of course, a PERFORM.  I assume we will allow inline
  Bob> performs (if that is not correct don't bother with the rest of
  Bob> these musings). So,

ADD a to b
  ON SIZE ERROR
      PERFORM
          ADD a to b
          NOT ON SIZE ERROR 
             MOVE confusing-text TO message-out
       END-PERFORM

  Bob> I think this is okay, the PERFORM statement is an imperative
  Bob> because of the END-PERFORM. (Incidentally for lurkers, inline
  Bob> PERFORM must have an END-PERFORM).  The PERFORM eats the
  Bob> conditional aritmetic statement even without an END-arith
  Bob> delimiter.

Thanks for this example.  I consider it equivalent to the original
one, the mandatory END-PERFORM notwithstanding.  I am maintaining
that an unmatched END-x should imply an appropriate END-x for any
unterminated conditional part that exists when it is encountered.
This isn't the letter of the law, but it does not affect correct
programs, and is arguably less astonishing than the strict
interpretation.   I'll say it again.  We do not have a floor and
ceiling standard.  No compiler has ever been denied certification
for permissive interpretation.

  Bob> So the grouping for imperative_statement_collection is
  Bob> something like the simple imperatives, the conditionals with
  Bob> explicit scope terminator, and the simple otherwise
  Bob> conditionals that are not specified in rules as having
  Bob> optional conditional clauses. .... and maybe some more.

  Bob> Strange as all that sounds, I think, IF with END-IF and
  Bob> EVALUATES with END-EVALUATES are not 'conditional' in this
  Bob> wrenched world, but are 'imperatives', ... so do you agree
  Bob> that these too need distinct rules to drive this supposedly
  Bob> 'context free' language?

I certainly agree that any statement that includes an appropriate END
is an imperative.  The standard says so unequivocally.  It must be
fairly obvious by now that I don't agree with the latter part.

  Bob> I acknowledge your expression that "it's hard not to see that
  Bob> they've left a loophole solely for the purpose of not making
  Bob> existing code invalid." And can say that many are frustrated
  Bob> by the challenging result. As you would know, working at the
  Bob> source code level in real application work, you can run into
  Bob> serious challenges mixing the old style with new scope
  Bob> delimited code. In new code it is easy to forget a scope
  Bob> terminator, but it is much easier to miss the need for one in
  Bob> old code when you insert or attach new style code near to
  Bob> old. For me the same dismay occurs when dealing with a program
  Bob> that has a mixture of excess EOS code, and forays into
  Bob> periodless code.  I can deal with either, but I'd rather do
  Bob> just one so that I can concentrate.

I don't want to denigrate the committee's efforts.  They have
sometimes shown solomonic wisdom in matters of interpretation.  In
this case, however, the rule that I would have preferred is at least
as defensible as the one that now obtains, but it would have been a
lot harder to state.  The standard is admittedly clearer by including
a sweeping generalization, but it excludes perfectly reasonable
cases like the PERFORM example you cited earlier.  It is my position
that we can adopt the more permissive course without repercussions,
compiling all correct programs correctly and only failing to diagnose
certain cases that are incorrect only in the most literal sense, and
whose intended meaning is intuitively obvious.  If you think adding a
huge amount of complexity to the processor to accommodate this rather
artificial restriction is a good use of our limited resources, I can
only say that I respectfully disagree.  

  Bob> Best Wishes Bob Rayhawk RKRayhawk@aol.com










  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.