Re: gnubol: problem 2.

[RKRayhawk@aol.com]

In a message dated 12/27/99 0:34:18 AM EST, wmklein@ix.netcom.com writes:

<< isn't the problem that when you see
 
  Something ( somethingelse
 
 that you don't know at this stage if it will then go on to:
 
  Something ( somethingelse :
     or
  Something (Somethingelse stillsomethingmore
     or
  Something (Somethingelse )
 
 Each of these does VERY different "things".   Once you DO get that next
 token, then you (should?) be able to resolve things, but it does require
 "reading fairly far" until you can really figure out what is going on with
 that first "something".
 
 Bill Klein
   wmklein <at> ix.netcom.com
  >>

I don't believe so.  The gramar tools can encode rules so that subsection 
that look alike can be concurrently scoped rules. 

So that several left-hand-sides (lhs) can be ongoing simultaneously

lhs1: Something ( somethingelse
lhs2 : Something ( somethingelse :
lhs3 : Something (Somethingelse stillsomethingmore
lhs4 : Something (Somethingelse )
 
The common section " Something (Somethingelse " actually becomes reduce to a 
singular sequence of states. At the state that Somethingelse as been gathered 
in the algorithm looks ahead, the various continuations in the various rules 
determines which if any rule stays alive. If the lookahead is the colon, then 
lhs2 is still in the running. As awesome as some of the grammar rule 
collections get to be, at execution time the parser always does things one 
step at a time.

With the friendly rules we sketch here, we sometimes have difficulty getting 
something like lhs1 to behave properly. Sometimes default logic in the tools 
will lead it to reduce and implement the lhs rule to readily, not paying 
enough attention to the lookahead match with alternative rules.  These 
effects are usually inadvertent results of precedence built into certain 
tokens, such as ";" or ")".  We usually need to rule to yield to these (so 
the rule need lower precedence then the tokens.  But somethings we do not 
want to glue onto that front formation, so we have to choose our precedence 
carefully.

((Putting the important problems of function arguements to the side.)) I 
think the subscript and reference modification stuff will work out fairly 
easily.  In fact, the reason that reference modification requires the colon, 
even when you want to leave the length out, is so that the compiler writer's 
would have a fighting chance with this stuff.

So anyway, for these references to data, I don't think we have to look too 
far ahead at any given time. The lookahead one (k=1) should be sufficient. We 
just need rules that engage the
precedence successfully.


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.