gnubol: sticky blocks

[RKRayhawk@aol.com]

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

<< 
 I am trying to get the hacks down to those that are needed because of genuine
 uncertainty combined with a need to reduce something at the same time. Often 
I
 can get around it by expanding out some of the nested productions. Sometimes
 not.
  >>


"exapnading out" is frequently useful.  'Flattening' things help too. Some 
time epsilon ambiguities can be zapped by flattening a subrule that has an 
empty alternatives, by lifting it up as two alternatives up above, one with 
the item one without; which is entirely different from the epsilon.


The language is filled with optional things that stupidly insist upon being 
right at the begining of a subrule: like ON of ON SIZE ERROR.  As if that 
were not enough I gather from the generous example positing the on some tools 
ERROR is optional. Because of a need to possibly reduce more than one 
alternative just before this rule and the optional attribute of ON, we would 
easily get into a r/r conflict when there are continuations with
  ....ON ERROR 
 and
  ....ERROR
should be elect to make "ON" into a subrule that hase an empty alternative 
(that generates the epsilon). The ...ON continuation and the ...epsilon 
continuation constitute the two continuations, which is too congested where 
we are trying to reduce two or more alternatives; such as ADD / ADD GIVING.

The problem is a teacher though. replicating the rules does the trick

some-arith: 
  ADD various_varieties ON SIZE ERROR block
|  ADD various_varieties SIZE ERROR block

This in the begining seems less attractive that subjugating ON to a subrule. 
Yet it can solve problems. The matter gets worse when we then begin to tease 
out the NOT alternatives

some-arith: 
  ADD various_varieties ON SIZE ERROR block
|  ADD various_varieties SIZE ERROR block
|  ADD various_varieties NOT ON SIZE ERROR block
|  ADD various_varieties NOT SIZE ERROR block

And if we must allow for a portion of the code base that can give us either 
SIZE or SIZE ERROR, maybe a situation like this gets worse (although 
specifially on the one a subrule with epsilon does not look problematic for 
the SIZE/SIZE ERROR !phrase!,.. I haven't tried that!)

In my own experimentation with this exact rule, per the discussions, I think 
yet another thing is required, beyond resolution of s/r and r/r requirements. 
 I think that we can not relegate the ON SIZE ERROR block to a subrule, we 
need to hang on to its branches at the verb node. This from scope 
considerations, not merely conflicts, but alternative strategies can raise 
rule conflicts as well.

So as a first approximation before doing any of the above ON/epsilon we have 
a different requirement to address: this set is real different so note well 
the details


some-arith: 
   ADD various_varieties  ON SIZE ERROR block-a
|  ADD various_varieties ON SIZE ERROR block-s  NOT ON SIZE ERROR block-a

Here explication is presented so that we bind properly (and also cope with 
some conflict issues).

I will comment on block-s/block-a in a moment. 

You can see from this that if you start explicating the presence or absence 
of the ON particle that rather than just duplicating rules you actually 
quardruplicate the second rule. I wont enumerate that lest I put readers to 
sleep. I personally do not think that is entirely unacceptable, and it might 
even be necessary! But it sure is ugly. In bison each such rule will need an 
action, which gets us into a genuine code management consideration, since 
many of those actions with be essentially identical..... so what that 
probably leads to is a subrule for the whole phrase that must lack epsilon on 
its front end (instead of a subrule for just ON as optional). We then need a 
YO version and a NO version.  anyway just ideas for you.


In the rules sketched above the two blocks are different. The outer block 
(there is only one block on the simple case) is a block-a. By which I mean a 
block of any statements. The block-s is a sticky block. In the case at hand 
it must be a sequence of one or more statements that ends with an arithmetic. 
That needs to be glues to the NOT ON SIZE ERROR. A block that does not have 
an arithmetic can't glue, there would be no subsequent alternate arithmetic 
conditional clause applicable.  

This requires the block-s recurse to be built differently from the block-a. 
Yer the other alternating conditional statements need an analogous 
distinction. For I/O conditional clauses, the block-s must end with the 
commencement of an I/O verb, or there is not way to glue an alternate AT END 
or INVALID KEY clause.  The subsetting will need to be distinct.

In the midst of the heystack of posts about SIZE ERROR, is the tiny needle of 
the possibility that some vendors allow flipping the sequence of positive and 
negative alternates. If the statements are not ordinal (that is if the simple 
sequential interpretation of syntax diagrams is not an imposed requirement, 
judge by code base) then we need this kind of thing (again rather simple for 
making this point):


some-arith: 
   ADD various_varieties  ON SIZE ERROR block-a
|  ADD various_varieties  ON SIZE ERROR block-s  NOT ON SIZE ERROR block-a
|  ADD various_varieties  NOT ON SIZE ERROR block-a
|  ADD various_varieties  NOT ON SIZE ERROR block-s ON SIZE ERROR block-a

Note the intentional careful placement of sticky blocks.

I believe that some posters are saying that this flip flop is not necessary.  
It is actually very easy, imposing no new r/r or s/r challenges. I am not 
advocating it as an extension if there is no code base motivation.   

This explication strategy confronts the bind issue head on.

If you groove on all this then you can atleast comprehend that I am saying 
(and we all care less and less about this) that a simple arithmetic, 
undelimited can not reduce as the last statement attached to the block-a, 
because that would be the exact precursor to the final portion of a sticky 
block block-s.  The exact answer is that a 'next level' would have to be 
concurrently scoped that would capture the simple arithmetic; and that is the 
meaning of two levels of conditionals. It is possible. I am not sure it can 
be done in k=1. That competitor would compete with the last rule just listed. 
It would have to have a precedence that defeats block-s; that release the 
subsequent clause to bind to a concurrent scope that captures it and binds it 
outwards.  The competitor would actually be a two level rule whose inner 
(2nd) branch competes with the grammar algorithms attempt to reduce the text 
as part of the outer (1st) branch of the above listed rule. Regrettably it is 
the _absence_ of an explicit scope terminator ten miles ahead that would 
cause the reduction. So if we could find a human to code this, we may not 
find a second who could understand it.

So anyhow, the entire thing become easier if we do not need the flip-flop of 
positive and negative orders for the alternate clauses. We should probably 
check a few compilers on that.
The reverse order consideration arises without nesting considerations. The 
NOT AT END clause seems most likely to bring the consideration about in real 
code.  I could see someone coding only the NOT AT END clause in a paragraph 
performed UNTIL file-status-eof. And then at a subsequently enhace the code 
and add the AT END clause after the NOT AT END clause.

So your idea of "exapnading out" relates to the alternate clauses in a big 
way.

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.