Re: gnubol: subsets

[RKRayhawk@aol.com]

In a message dated 11/20/99 10:26:11 PM EST, mck@tivoli.mv.com 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 }
    ;
  >>

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

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

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

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

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

But yes, I think there are atleast two, sometimes four in these burdensome 
sets.

There is a variation of this that is even more strange, but I don't think it 
is any different to code. A conditiional branch can have, of course, a 
PERFORM.  I assume we will allow inline performs (if that is not correct 
don't bother with the rest of 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

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

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

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

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

Best Wishes
Bob Rayhawk
RKRayhawk@aol.com










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