Re: gnubol: refmod and soft edges

[RKRayhawk@aol.com]

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

<< The wayward refmod will not escape.  It is simply an
 unexpected element if the rule cannot accept it.
  >>

With time we will see more clearly what happens upon unexpected encounters. 
For example,
suppose a subscript and a reference modification are reversed.  Lacking an 
error production for that, we would have to see what happens to the rule, and 
what happens to the clause recursing into the rule, and what happens to the 
outer rule recursing into that. My idea would be to stop any anticipatable 
problem inside the sub rules for referencess. References are easily damaged 
and I feel that we should devote cosiderable effort to trapping damaged 
references, and keeping the rule that wants a reference on its feet (by 
commuting error flags upward). 

My idea is simply to prevent parse breaks on the references.  If we do not 
then latter portions  of deeply nested source code will possibly then look to 
the parser as numerous unmatched conditional clauses, producing spurious 
diagnostics.

The references are where the procedures hit the pavement.  I do not believe 
that elaboration there is exponential, and I mean that as simply direct 
response to the use of the term technically.  The compiler is a vehicle with 
multiple touch points, basically references to data and references to 
procedures. Strengthening the touch points is linear, because it is the 
bottom of the hierarchical parse structure.

What is not linear is the surface of the procedure division. It is highly 
recursive. Breakage deep in the recursion could cause the latter portions to 
be unrecognizable.  Surely some breakages are severe. But I would not put 
imperfect reference to data or procedures in the severe disruption category.

I am holding onto this line discussion not to tire you of it. What I foresee 
is that when we get to the conditionals, we are going to face great 
difficulty in maintaining scope recursion. Error tokens in the rules that 
maintain conditional clause scope will definitely create ambiguities we can 
not resolve, in my anticipation. Consequently we do not want to try to 
capture reference junk as flyouts from the basic rules for the verbs. That 
will make it extremely hard to subsume the basic rules for the verbs into the 
rules that will control recursion into conditional clause scope (because of 
the presence of ambiguating 'error' tokens at various ends of the rules we 
try to subsume). 

Thus we need to trap disruptions in references as low as possible. So that, 
for example, a PERFORM data-dame, or a MOVE procedure-name, does not exit the 
reference rule or the rule for the verb (although obviously error toggles 
must flip on).

I am very certain that when we try to glue this stuff together at the top 
that the epsilons from 
optional sub-clauses, and the ambiguating 'error' rule terminators will lead 
to alternatives that are impossible for the parser to select from based upon 
lookahead.

If we build the parser from the tokens up, we will miss the major problems at 
the top until it is too late. 

If you wish to see why we probably do not want disrupted references to pop 
out, start the parser work from the conditionals, recurse in while the 
conditionals are in scope, emde conditionals inside of conditionals, look at 
how many optional and 'error' issues you see before you even encounter 
something down at the very low level of an optional phrase or good or poor 
references. 

IMHO if something looks at all like a reference it needs to be tacked down 
right away, good or bad. Application of notions of associativity to reference 
modification, or even precedence implemented as optimistic structures, can 
not bottle up the errors that are likely. If the coder damages a reference 
that is their fault, but if we loose track of conditional clauses that is our 
fault.  

If you don't trap reference problems with brutish enumeration down deep, you 
will decorate intermediate rules with 'error' catchers.  It is when you then 
go to the next level that you will see you can not merge it together up 
higher. Honestly, try all of this the other way around.

Don''t just write some optimisitic rules for the arithmetic verbs, but try to 
write the rules that permit the conditional clauses to recurse, attaching 
more and more verbs. Dealing with scope delimitation is going to require lots 
of variation. In that intermediate level you will need optional rules 
(epsilons) and 'error'  symbols, and some error productions. Honestly, if you 
do that you will see that you will hope for nothing to be floating out of the 
fundamental parts of the verb rules; you will find that epsilons or 'error' 
symbols on the basic rules will compete with the same at a higher level that 
you want to attach to compensate for the language alternatives inside of 
conditional clauses and for coding errors in that area.

The best hope for hardening the edges of the basic verb rules is to capture 
reference errors inside of reference rules (not on the way out therefrom). It 
is an opion, but strongly felt, that we will need to be brutish; linearly 
brutish, not exponentially brutish.  It is not that I am in favor of lots of 
low level rules forf un. Once you see how difficult it will be for the 
conditional clauses to stay on their feet in this language, you will know 
that you do not want the low level stuff to pop out; and in my opinion, you 
will see the need to keep the basic rules free of soft edges if you start 
your analysis from the top down, rather than from the tokens up.

I know for sure that this seems all a bit irksome to some, but really the 
complications at the top will make it necessary for the low level rules to be 
elaborate. The usability of the tool will be diminished if we can not stay 
well within recurses of conditional clauses. The robustness of those recurses 
will be entirely dependent upon specification of intermediate rules that have 
few if any epsilons or ambiguating 'error' symbols on leading or trailing 
edges.

I am saying all of this not to advocate some personal preference. Really! 
This gnubol effort is huge.  I am hoping that the participants can see the 
full extent of the requirements before they invest a personal involvement 
that leads to some later disappointment. Trust me, I am not trying to slow 
you down. One meaning of the use of the term 'exponential', might be a 
coloquial sense, that really someone is just hoping that there is not much to 
do down at that little unimportant level of references to data and 
procedures. This is meant as a positive and supportive message; if we do not 
elaborate at the low level, the top will not hang together.

I am increasingly convinced that PCCTS hides ambiguities from us. The 
extraordinary elegance of the available syntax can not be matched in my view. 
But I do believe that if you start from the top with the conditionals, and 
attmpt to include these various rules optionally wihtin eachothers 
conditional branches, you will see that the low level needs to be very quiet 
as it percolates up, and I think, gradually move closer to the notion I 
present for consideration: brute force will be needed where the vehicle hits 
the pavement.

Best Wishes, and really my posts are trying to help depict the size of the 
project that I see,
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.