Re: gnubol: Re: which parser tool

[RKRayhawk@aol.com]

In a message dated 11/13/99 10:46:33 PM EST,
Tim Josling tej@melbpc.org.au writes:

<< 
 At present the only case for backtracking I have run across is the
 reference modification/array ambiguity. I don't see that forcing an
 explosion. Refmods are only allowed in certain circumstances so you
 could use a less powerful form of identifier in most cases that
 eliminates the suspense.
  >>

As some previous interaction has brought out, we can go after just valid 
programs or try to go after a larger class that includes likely errors and 
errors that would cause trouble if we don't aggress them.

You posit a piece of code like
  if a and not b and c of d of e of f
which in a goal seeking parser context has a portion that would appear in 
   move c of d of e of f to dest

My general notion is to reduce any such 
  c of d of e of f
as a basically a rule unto itself, and naturally include its symbol name in 
rules for the IF and MOVE.

But further that sub rule might actually be very involved.  You mention a 
count of a hundred lines to deal with part of this issue in the preprocessor. 
I actually am not exactly sure what you meant, a hundred C statements a 
hundred rules? If the approach I am hinting towards is viable it is bigger in 
either sense. But I am already thinking there is something like an AST that 
can be decorated with error flags that commute up (if that is proper 
terminology). This approach might get the IF and MOVE rule(s) partly  out of 
the business of diagnosing syntactically non-conforming data references. 
There would have to be a infrastructure for the diagnosed errors to flow on. 
In effect the syntax errors are transparent to the higher-level rules that 
subsume the robust diagnosing sub rules.  Yet if the even if the data 
reference is diagnosed unto itself the appropriateness of that _type_ in the 
IF or MOVE is something I would itemize as well as alternate rules.

Do you see from these generalizations how this potentially allows the higher 
level rules to stay on their feet? The fact that errors were detected must 
live on.

I am strongly convinced that we can not allow something like an IF or MOVE to 
stop parsing if it is at all close to right.  COBOL is a heavily nested thing 
in real programs as you know. We just can not loose our depth perception on 
something like a munged data reference.

By the way care to guess about total parser rule count before its done?

---------
Separately a  potential issue here is left hand side reduction (but not 
really inherently). Actions can be coded early in left hand reduction, that 
could get us commited, before sub rules (that are further to the right) are 
diagnosed. 

I emphasize that this does not happen inherently. It is just that if the 
parser rule coder commences to use the early reduction on the left and places 
the action code before the reference to subrules, then we could stream either 
incomplete things to the semantics, or things we would rather tag as errors.  
That is not actually a necessary coding style. You can really wait to the 
end. 

The early examples seem to suggest that coders might be willing to start 
coding the commit actions early. There's not enough action-like code around 
to say the pattern has gotten started.   But the nascent form is the 
proliferation of miniature state machinery in the 
<<pccts-swith-like-actions>>. I am no expert on this tool, but those little 
puppies are definitely being sequenced in time. That is not the same thing as 
embedding the real action code in the middle of the larger scope rules, I 
know. But we will have a few challenges,
 like ...
    PERFORM yourfavoriteabender
        { integer TIMES
            /*tempting reduction point for left handers*/
         | VARYING x BY y UNTIL the-millenium
            /*alternate reduction point */
          }?

This kind of thing might get set up in the parser definition. And forgive my 
PCCTS if its a little imperfect. The idea is we want the TIMES clause or the
VARYING clause but not both.  Maybe someone would put some bullet-proofing in 
there to detect that the TIMES clause had happened and go ape if the VARYING 
clause also happens (that bring up a question I am really just so anxious to 
get at, but another day..)

I am really just after two things here. If we reduced early at the TIMES 
clause in 
a situation like this we might have real trouble reversing the effect if we 
find later errors. Mostly my concern is the stability of the arrangement as 
the emited result streams into the semantics.  

You do not have to do it that way, you could (and again don't get conerned 
about the PCCTS, this is an approximation) ...

    PERFORM yourfavoriteabender
        { integer TIMES
         | VARYING x BY y UNTIL the-millenium
          }?
         /* now here reduce at the very end,
             but use various flipped switches to determine 
             which form had happened */

In a certain sense this is analogous to the position you _might_ usually wait 
for in a right hand reducer. You can actually get into the exact same trouble 
I am describing in right hand reducers. But coders think of the tool 
differently. 

So this is more of a warning I suppose than a request for specific response.

What I think I see is a pattern that suggest the possibility that the 
orientation to left hand technology may lead to early reductions representing 
partial reductions, that will possibly create difficult problems in the 
interface to semantics, if errors are later detected and handled, or later 
cause the underlying tool to abandon the sequence.  Surely some of my 
disquietude comes from lack of experience with PCCTS.  But in the files are 
scripts with lots of commitments to miniature state switches that could 
themselves be orphaned, in the way I am saying early committed actions could 
slice off front ends but not complete sequences for the semantics interface.

But moreover, what we really need is a design of the interface to semantics. 

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.