Re: gnubol: X-WHEN stack

[RKRayhawk@aol.com]

In a message dated 12/6/99 4:28:25 PM EST, 
the ever resilient Tim Josling, TIMJOSLING@prodigy.net writes:

<< OK I think I understand. What about this though?
 
 evaluate true
    when a1 = a2
      search b varying ix
          when b(ix) = 1
                display
          when <* confused right here
                 other
                      display ....
 #
 
 The lexer has to pass the type of 'when', but it has not seen the 'other' 
which
 tells the reader that the when belongs to the evaluate: 'when other' is not 
valid
 as part of search. And it is not just one token of lookahead, although I 
hesitate
 to claim it is 'infinite'. You can look more than one token ahead but then 
you
 are writing my prescanner.
 
 Is the new floating comment delimiter (see above) tacky or what?
 
 Tim Josling
 
  >>


You are right the simple approach I sketched will bubble up the 'confused' 
WHEN as an 
S-WHEN, and S-WHEN OTHER is an error. Depending on the exact set of rules 
there is still hope.  In the discussion that you have been so kind to 
consider, our primary objective is to get the _preceding SEARCH WHEN rules to 
reduce upon sighting of S-WHEN as a lookahead. 

Even in the confused situation, that much happens.

Our secondary goal is to get the S-WHEN to glue to the SEARCH WHEN-recurse. 
Turns out that if that recurse is looking for 
  S-WHEN+condition-expression 
as it's next plate to stack, 
then the stack recurse atrophies upon encounters with _code_ that  looks like 
this
  S-WHEN OTHER ....whatever

I am not saying that therein is a competent 'implicit' end for SEARCH (that 
is a couple of steps beyond my initial thoughts in reaction to your question).


But, It may be possible to layout alternate rules for EVALUATE that allow it 
to see whether
   E-WHEN OTHER ....
     ( previously_suggested_stack_pop(single, verify_its E_off); }
or 
   S-WHEN OTHER ....
     {  stack_pop(double, verify_its_S_off_then_E_off); }
 as its alternate conditional branch (The E-WHEN tail recursion  being its 
first conditional branch).

These rules would, in the example posited be concurrent with and thus 
competitive with 
the SEARCH rules. When the SEARCH rule atrophies, the surviving EVALUATE 
rules pick up the pieces. That requires a successful reduction of the SEARCH 
WHEN recurse, which is different from the mere reduction of the last WHEN 
(plate on the stack).

From the discription thus far it looks too late, but still there is hope.  
you might be able to code a special nudnick rule in the SEARCH WHEN recurse 
that looks something like
the last part of this

search_when_recurse :
   S-WHEN cond stmt_block
     {/* love the normal stuff */ }
 | search_when_recurse  WHEN cond stmt_block
     {/* stack 'em high */} 
 | search_when_recurse  S-WHEN %prec reduce_me_upon_OTHER    
     {/* don't let this distract you (this too snares the animal) */ need 
diag here too();} 
 | S-WHEN %prec reduce_me_upon_OTHER
     {/* gotcha! */ 
      error_diagnostics(lineno, "scope terminator assumed on SEARCH");
      }

and now modify the trick at EVAUATE to compensate for the fact that the S-WHEN
just got eaten, so the initial S-WHEN token gets lopped off

alternate rules for EVALUATE's when recurse might now look like

   E-WHEN OTHER ....
     ( previously_suggested_stack_pop(single, verify_its E_off); }
or 
   OTHER ....
     {  stack_pop(double, verify_its_S_off_then_E_off); }


Actually I would in this latter scenario put the initial pop of S-WHEN up in 
the special truncated rule of SEARCH's when recurse.  And down here in 
EVALUATE's special 
standalone OTHER I would revert to just pop E-WHEN from the X-WHEN stack. 
That looks neater anyway, and we may need to be able to see OTHER in code 
that has simply not been graced with WHEN for the WHEN OTHER. (In early COBOL 
'85 that is actually an error, in which code circumstance we want to be 
resilient.  In later standards it might be otherwise).

So to be exacting at the risk of being boring: this sketch might be helpful:

search_when_recurse :
   S-WHEN cond stmt_block
     {/* love the normal stuff */ }
 | search_when_recurse  WHEN cond stmt_block
     {/* stack 'em high */} 
 | search_when_recurse  S-WHEN %prec reduce_me_upon_OTHER    
     {/* don't let this distract you (this too snares the animal) */ need 
diag here too();} 
 | S-WHEN %prec reduce_me_upon_OTHER
     {/* gotcha! */ 
      error_diagnostics(lineno, "scope terminator assumed on SEARCH");
     /* elevated this pop */
     ( previously_suggested_stack_pop(single, verify_its S_off); 
      }

/* partial listing */

evaluate_when_recurse :
   ........
 |   E-WHEN OTHER ....
     ( previously_suggested_stack_pop(single, verify_its E_off); } 
 |  OTHER ....
     (  /*  
           possibly dual purpose
              1) catch OTHER flyout from implicitly terminated SEARCH
              2) catch  EVAL ... WHEN ... OTHER ...
                   Where OTHER should have been WHEN OTHER
       */
      previously_suggested_stack_pop(single, verify_its E_off); 
     } 

We may need to distinguish the dual purposes contemplated above. Maybe $-1 
can disambiguates it.  That kind of inherited attribute techniques is usually 
pooh-poohed. But in this case it might not be too unreasonable to code 

  if ($-1.llval != WHEN) // (or S-WHEN or E-WHEN)
 then deal with this as the warning/reject thing, .. otherwise it is _some_ 
kind of an X-WHEN OTHER so we are recovering from some trick: so let it 
through. This situation may warrant an exception to the general rule.  We 
need only minimum bullet-proofing to check that $-1 is not null (seems 
unlikely, but if you do anything like this, protect the dereference from 
nullity).

Hope that helps.

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.