Re: gnubol: subsets

[RKRayhawk@aol.com]

In a message dated 11/18/99 8:51:23 AM EST,
Michael McKernan mck@tivoli.mv.com writes:

<< 
 There was a thread a while back on a similar ... subject, when
 Laura was in the midst of the Russian Armory experiment.  As I
 remember it went something like this.
 
     ADD a TO b
     ON SIZE
        <many statements>
        SUBTRACT c from d
        ON SIZE
           <many more statements>
     END ADD
 
 Now, the SUBTRACT is illegal because it is not an imperative
 statement, not having an END SUBTRACT.  The imperative statement
 requirement is the same kind of legalistic prohibition.  Accepting
 the fragment as written causes no difficulty in parsing, and its
 meaning is clear, but it appears to require an extraordinary effort
 to diagnose because you have to be aware that the SUBTRACT is in the
 scope of a construct that does not allow conditional statements when
 you arrive at the END ADD.
  >>

I think that I am at long last getting to the END :-) of this thing and it 
looks a whole lot more reasonable to me now.  I think it is not political at 
all.  A way of looking at this is that the explicit scope terminators enable 
us to put anything within anything. That is in part what they are for. So a 
conditional statement becomes an 'imperative statement' because of the 
presence of the scope terminating element.  That is really easy actually.  

See, it is like this. You do not need to keep track of the fact that the 
inner arithmetic statement is within the conditional branch of some other 
arithmetic statement.  All you need to do is to define an explicitly 
terminated arithmetic statement as distinct from an arithmetic statement that 
is not explicitly terminated. That is much easier than doing anything like 
keeping track of the from within where issue.

The idea is that the set of all explicitly terminated arithmetic statements 
(incidentally with or without their own conditional clauses) come within the 
gambit of 'imperative statements', as would simple statements. Conditional 
statements that do not end with an explicit scope terminator get themselves 
gathered up under ' conditional statement'.  

Now any and all arithmetic statements that have a branch like ON SIZE error 
can at that point only subsume an 'imperative statement'  as so defined. In a 
certain sense this is just lookahead, but for this kind of language 
requirement you need some distinct intermediate rules to accomplish the 
alternate gatherings.

This bag of tricks happens for a number statements categories beyond merely 
the arithmetic and COMPUTE statements; for example many I/O verbs.

The history of the standards committees is long and star studded. But really 
the scope terminators make a lot possible, they are very interesting. The 
result of the political fighting is a benefit of inestimable value to the 
compilere writer; the explicitly terminated statements are definitely a 
different thing from non terminated statements. It is nice to be able to rely 
on that.

I feel that the matter is not legalistic because the compilers I am 
accustomed to not only allow ON SIZE ERROR but also NOT ON SIZE ERROR. There 
is no ordinality to these. That is the trip-up that halts application of 
simplistic notions of associativity. In the following note the NOT ...

     ADD a TO b
     ON SIZE
        <many statements>
        SUBTRACT c from d
        NOT ON SIZE
           <many more statements>
     END ADD

Now the originals posters notion "Accepting
 the fragment as written causes no difficulty in parsing, and its
 meaning is clear" is not correct. Ditto for the following ...

     ADD a TO b
     NOT ON SIZE
        <many statements>
        SUBTRACT c from d
        ON SIZE
           <many more statements>
     END ADD


If the conditional branch on the first arithmetic statement can only find 
explicitly scope terminated conditional statements then the END-ADD glues to 
the inner arithmetic statement, and so obviously we would have to glue the 
inner conditional to that same inner arithmetic. But if instead, we let the 
inner arithmetic be open ended, it is _then_ that things are complex because 
we do not know which arithmetic statement owns the alternate conditional.

The READs I work with have INVALID KEY and NOT INVALID KEY, and AT END and 
NOT AT END that display the say behavior.  

Even if you want to impose ordinality on the phrases, a portion of the 
problem persists. It is not political at all.  If we required the ON SIZE 
ERROR to come before NOT ON SIZE ERROR, then the challenge (as above)...

     ADD a TO b
     ON SIZE
        <many statements>
        SUBTRACT c from d
        NOT ON SIZE
           <many more statements>
     END ADD

still defeats you with ambiguity if the conditional does not require an 
explicit scope terminator.  

There is a small chance, and this is intended only as cross reference to 
bring out the fullest discussion, ... there is a small chance that the use of 
left-hand reducers have led contributers to think the wrong way about these 
challenges. We do not track our way into recurses, we must track our way out. 
That is really very very different.  Any of these challenges can be handled 
or mangled with either left-hand reducers, or with right-hand reducers.  But 
the left-hand reducer technology is _maybe_ getting some of us into the wrong 
frame of reference.

We need to track on the way back out, and before we get all the way back out 
on any given rule, lots and lots of strange stuff may have happened down in 
there.  Like say seven ON SIZE ERROR clause for the same arithmetic statement 
(without any of the above exonerating considerations),  or like VARYING 
clauses, well formed, attached where they might not ought to be, say a SORT 
verb, or the INPUT PROCEDURE clause there of.

In the discussions we are having note that a coder could _easily_ leave off 
the explicit scope terminator. When that happens we need the rule that 
catches it or we will miss every thing in the second conditional clause, 
which could be huge. So the conditional statement in all those places where 
conditional statements should not be, needs to be coded as yet another rule 
in order to diagnose it (and it will be truely difficult to do that without 
ambiguity in the technical sense!).

But I don't think this stuff is political. The lack of ordinality in the 
conditional branch clauses is down right convenient actually. To be honest, 
considering where we must draw from for staff, it is a stroke of genius that 
mere associativity was not brought forward from the conditional IF statements 
as a model of how to resolve the conditional clause nesting problem. As 
intricate as our discussion might get in this project, at the application 
level the explicit scope terminator is very easy to understand. Although a 
full appreciation of some of the intricacies is not for beginners, guidance 
from senior staff is real easy to get, 'put an END-arith on there and you 
will be good to go', and if the staff member is real tender just 'put an 
END-arith everywhere, and don't come back until you do, please'. 

Incidentally we can turn this whole thing inside out and start looking back 
to certain grammars we have experimented with an note that some of them 
impose no ordinality on clauses that actually are supposed to be in order, 
and some of the rules don't happen to count the number of occurences of 
reductions.

For example, maybe we do have a rule around that reflects that a VARYING 
clause can have as many as three sections, or maybe we are letting it go 
wild. But I don't think we know if we have a PERFORM with two or more VARYING 
clauses.  This kind of thing, IMHO, is syntax not semantics.  And you 
approach it soon after teasing out the includable imperatives (simple and 
scope delimitted conditionals) from the conditionals, because then you are 
back to the original statements that have conditional branches and how many 
times did they infact occur?

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.