Re: gnubol: refmod again

[Michael McKernan <mck@tivoli.mv.com>]

>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Tue, 30 Nov 1999 02:54:21 EST

  Bob> Just so it won't feel so bad later, I'll flag these valuable
  Bob> exchanges with the note that we will be better off just using
  Bob> precedence (in the grammar rule sense), and not hoping to do
  Bob> much in COBOL with associativity.  Maybe you can get somewhere
  Bob> with COMPUTE, but I fear that idiosyncracies in subscript
  Bob> (like unary positive) could cause you grief.

Subscripts are certainly idiosyncratic in the sense that general
expressions are not permitted, but I don't see a problem unless we
try to extend the language in that direction.  The present rules are
horrible, but not unparsable.  This is apparently legal and
represents two subscripts.

	   (foo + 0 + 1)

  Bob> But even at that precedence can usually be represented in rule
  Bob> structures.  And that, rather than associativity
  Bob> specification, leaves you more flexible for special case
  Bob> handling and for error productions. This is at odds with the
  Bob> evolving ethic of being PCCTesque, if I might koine a
  Bob> phrase. In the end you will have to undo the concise rules,
  Bob> and lay it all out brutishly.

No, pccts is an LL/K generator that produces a recursive descent
parser.  The precedence YACCisms are not offered, so it's just a
conceptual thing in any of my remarks.  This is what I think the
expression grammar looks like.  It uses iteration for left
associativity and right recursion for right associativity.  The
"add_op:ADD_OPR" notation may be unfamiliar.  "ADD_OPR" is called
a token class and represents both PLUS and MINUS.  The preceding name
is a variable that captures the actual token which  would be used
in any action associated with the production.

	    arith_expr
		    : term ( add_op:ADD_OPR  term )*
		    ;
	    term
		    : factor ( mult_op:MULT_OPR factor )*
		    ;
	    factor 
		    : unary { POWER_OP factor }
		    ;
	    unary
		    : { unary_op:UNARY_OPR } primary
		    ;
	    primary
		    : OPAREN arith_expr CPAREN
		    | NUMERIC_LITERAL 
		    | identifier 
		    ;

  Bob> If you don't then you have either fooled yourself into
  Bob> thinking you got things done quickly, when you have left the
  Bob> whole project to semantics, or you will have difficulty
  Bob> righting the parser(s) in such a way that they do not generate
  Bob> lots of confusing error messages down stream from one or two
  Bob> minor errors.

I, for one, am not underestimating the scope of the semantics effort;
I've been there.  It's still not clear to me that smart parsing can
mitigate it to any significant extent, however.  With some
exceptions, separation of concerns still seems right to me.

  Bob> Particularly, IMHO, it will not be a good plan to try to
  Bob> conquer qualification with operator precedence defined by
  Bob> means of associativity. At the level of references we should
  Bob> use brute force elaboration of rules to isolate as many
  Bob> problems as possible, and keep the verb constructs moving
  Bob> forward.

Still a little too abstract, but if it doesn't fit, don't force it.

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