[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Parsing nested statements: was Re: gnubol: subsets



>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Thu, 25 Nov 1999 13:31:14 EST

      <snip>

  Bob> The standard also has the word "...such...", which I believe
  Bob> allows the interpretation suggested here, but leaves us with
  Bob> _no_ definition of what to do when the prior statements
  Bob> already have '"..such...", as in when the NOT is removed

 MULTIPLY meg BY mega GIVING giga
    ON SIZE ERROR
         ADD 1 to count-errors
     ON SIZE ERROR
         ADD 1 to success-count
   .


  Bob> All would agree we have an error. Some would attempt then to
  Bob> glue the second ON SIZE ERROR to the inner atithmetic, But if
  Bob> you try to justify that by the word "...such..." meaning that
  Bob> the outer arithmetic already has such a (positive logic) ON
  Bob> SIZE ERROR clause, you will write a compiler that is _M_U_C_H_
  Bob> more complex than what I advocate.

I realize that you are not claiming that this is the reasoning that I
used, and it assuredly is not, but I'm beginning to suspect that I
have not made my proposal sufficiently clear.

The _only_ deviation that I want to make from the standard is that we
not enforce the imperative statement rule.  The imperative statement
rule is not logically necessary, just as fully parenthesized
expressions are not logically necessary.  Just to choose something
that is right associative, as I believe nested statements are, let's
say I write something like this.

      x ** y ** z

The tree the parser gives me is this

           y    z
            \  /
	     \/
         x   **
	  \  /
           \/
           **

If that's not what I intend, I can say instead

       ( x ** y ) ** z

and obtain this tree

           x    y
            \  /
	     \/
             **    z
	       \  /
                \/
                **

Similarly, If I write this

	   ADD 1 TO A
	      ON SIZE
	         ADD 1 TO B
		    NOT ON SIZE
	   	       DISPLAY "foo"
	   .

The indentation indicates the meaning that would be the default.
Once again, if that's not what I intend, I can write this instead.

	   ADD 1 TO A
	      ON SIZE
	         ADD 1 TO B
		 END-ADD
	      NOT ON SIZE
	   	 DISPLAY "foo"
	   .

So I can precisely control how the SIZE phrases are applied.

How do we do it?  Simply by using the "statement" non-terminal
instead of "imperative" in the grammar for size error.  This is the
pccts rule.

size_err
	: {ON} SIZE {ERROR} statement
	  { ( NOT {ON} SIZE )? NOT {ON} SIZE ERROR (statement)+ }

	| NOT {ON} SIZE {ERROR} statement
	  { ( {ON} SIZE )? {ON} SIZE ERROR (statement)+ }
	;

Why should we do it?

(1)  All correct programs will still compile correctly.

(2)  No lookahead or additional rules are required.

(3)  Maybe IBM does it that way ;-)

I guess only the last one counts.



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