Re: gnubol: Re: Magic tokens

[RKRayhawk@aol.com]

In a message dated 12/4/99 8:47:38 PM EST, TIMJOSLING@prodigy.net writes:

<< 
 add:
 stuff a_size_error
 ;
 
 a_size_error:
 size error imperatives
 |not size error imperatives
 | size error imperatives not size error imperatives
 | not size error imperatives size error imperatives
 ; >>

let me slightly mark that for a comment

 a_size_error:
 size error imperatives
 |not size error imperatives
 | size error imperatives-S not size error imperatives
 | not size error imperatives-S size error imperatives

I commented on this in a different post but let me say two things for your 
consideration. The imperative block I mark here as imperatives-S can not just 
be a bland block.  That block must start with an arithmetic, and not yet have 
its [NOT] ON SIZE ERROR clause.  I call that a sticky block. This is by 
definition of the situation the longer rule is relating to.  That 
imperatives-S block must be defined differently than the simple imperatives 
type block.  Similar distinct block constructions will be necessary for the 
I/O set, etc.

Another thing I have toyed with is to write these rules a little differently 
by chopping the end off! As in ...

 a_size_error_plate:
 size error 
 |not size error 
 | size error imperatives-S not size error 
 | not size error imperatives-S size error

Where the imperatives block has been axed.

That is not only useful under some strategies but is actually necessary. This 
kind of rule really belongs in a recurse, ... it is the upper level recurse 
that will add the imperatives block at the right edge, and indeed that is how 
acceptably terminated nested conditionals are going to be feasible. This is 
much more clear if you start from the top down in the grammar. Eventually you 
see that the ADD lead and the END-ADD are subrules of major rules that are 
just trying to harness the conditional recurse concurrent scopes at the right 
edge.

If you try to build out from the ADD token, your need to find a matching 
END-ADD terminator makes it impossible to recurse dynamically on either side 
of the conditional alterations. The ADD and the END-ADD are incidental to the 
real structure which is just a super deep recurse possibility. An 
intermediate rule must compel the initial and terminal tokens to synchronize.

With that notion in mind you can work with something like

sticky_stack:
  ADD_lead  a_size_error_plate ADD_tail
| SUB_lead  a_size_error_plate SUB_tail
| sticky_stack  ADD_lead  a_size_error_plate ADD_tail
|  sticky_stack SUB_lead  a_size_error_plate SUB_tail

That is neither intended as perfect or anything like exhaustive. My point is 
that the stacking of conditionals arougn the arithmetic ON SIZE ERROR can be 
abstracted. The stacking infrastructure is indifferent to the particular 
arithmetic skin.  But the skin needs matching tokens.

Leaving the internal syntax 'plate' pattern open at the end of the 
conditional phrase allows the sticky stack to recurse, ... in definitely. an 
interesting added rule would be perhaps something like 

|  sticky_stack SUB_lead  a_size_error_plate error

which tries to trap damage after some segment of the stacking that got started
with a SUBTRACT and a conditional phrase but then found problems.

The plates of the stack that have two portions compete with one another. As I 
understand the drift of concensus, we want the later competing scope to 
reduce and obsolesce the earlier. The competition between recurses is very 
cerebral. It involves conflicts we ! want !.

If we go back to your sketch


add:
stuff a_size_error
;

a_size_error:
size error imperatives
|not size error imperatives
| size error imperatives not size error imperatives
| not size error imperatives size error imperatives
;

I will tell you that one small, minor, problem that happens with this 
approach is that if this is in a recurse, there is a tendency for the recurse 
to gobble up its last part down in the imperatives to the right of your rules 
and then gobble up atleast one more statement. This possible problem will 
depend entirely upon your style in the upper rules, but the problem is to get 
the conditional clauses to recurse you have to make them hungry.  If they 
feed internal to a recurse located on the right side of that rule, that is 
down under the rule; then the outer rule that is motivating this will have a 
tendency to recurse further right after this rule pops.  This is potentially 
valuable information, I can assure you, because as you try to get your 
internal conditional stuff tested the outside problem will show up on even 
simple test cases when you first start and you will think the deep recurse is 
still wrong.

All of that is hard to express. But the real purpose of the conditional 
clause structures is not to iterate. It is just an accident that the inner 
imperative-S block needs to spin until it get a related statement or it never 
reduces (eventually obsolescing in favor of a reduction on the shorter 
simpler rules).
When you shake loose like that you relalize that you really don't have a 
natural reason to plug the right side imperative block in this particular 
rule. And experience I am sure will show you that your actually desire to not 
locate it down, there, the recurse actually is up above, which recurse 
involves a newly instantiated competing rule of the same nature, displaced by 
one segment.

THe key to understanding is that the competition looks something like this

| size error       imperatives-S not size error 
| not size error imperatives-S size error 
| >>>>>>>>>>>>>>>>>>>>> size error imperatives-S       not size error 
| >>>>>>>>>>>>>>>>>>>>> not size error imperatives-S size error 

These concurrent scopes compete and manage the initial and terminating token 
matching problem. For this to be feasible the recurser that sets up this 
competition must layout some basic simple blocks as competitors as well.

Anyhow, I hope that isolates the conditional clause as an abstractable 
syntactic pattern. The situation is kind of fun. Not only does this apply as 
a template for the other conditionals.  But in certain rules the entire 
shooting match must be brought together as possible competing concurrent 
scopes.

Bob Rayhawk









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