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

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

>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Fri, 26 Nov 1999 14:26:35 EST

  Bob> In a message dated 11/25/99 11:09:41 PM EST, Michael
  Bob> McKernan,mck@tivoli.mv.com writes:

  Bob> << Bob, I trust that someone among our fifty-two members will
  Bob> be able to comply with Tim's request to run the experiment for
  Bob> us.  Let's let the mainframe compiler be the arbiter.
  Bob> Ultimately the compiler determines what is in the code base,
  Bob> right?
 
  Bob>  Best regards,
 
  Bob>  Mike
  >>>

  Bob> It is easy to be comfortable with your excellent
  Bob> approach. While you all sink some energy into that charted sea
  Bob> to see that it is charted, I shall endeavor to deploy an
  Bob> actual solution for the "...not...such..." consideration which
  Bob> is definitely a chess game, even though there are those that
  Bob> think no such gameboard is relevant.

Well hell, if we're talking about being compatible with existing
implementations and it is possible to determine the behavior of those
implementations, we would be derelict not to try to do so.  

I'll attach a first test program to the end of this note which,
admittedly, assumes the behavior that I want.  If it should fail, we
may need other programs to probe the real behavior.  I haven't shown
this program to any compiler, so there may be some error in it that
I've overlooked, but I think it's clear enough what is intended.

There's no reason to limit this to IBM mainframe.  If people have
access to other '85 compilers, I hope they will try it as well.  It
would be gratifying to find that there is industry concensus, at
least in one area.

  Bob> If I can sketch it, I will share notes, and atleast a minimum
  Bob> bison file to show the concept specifically.

  Bob> At a higher level we all have a major issue before us. If the
  Bob> vendors are deploying different semantics on arithmetic and
  Bob> I/O conditional syntax, we have the largest possible coding
  Bob> task before us. That represents a major turning point, if
  Bob> real. So heads up.

There may have been clarifications, etc. that I'm not aware of, but
the standard has always been notoriously weak on spelling out
detailed semantics.  Do we have any guidance on intermediate results
yet?  

In any case, being all things to all men, is really hard to schedule
;-) 

  Bob> But whatever the direction this imparts, clearly the tenacity
  Bob> displayed by one in possession of as much technical depth and
  Bob> breadth as you will mean good things for this project.

Thanks, Bob, but I probably wasn't tenacious enough.  I was ready to
drop this one until I realized that you were talking about a real
implementation that we could actually get some information about.  

  Bob> Best Wishes Bob Rayhawk RKRayhawk@aol.com



	identification division.
	program-id. cobol-test.
	data division.
	working-storage section.
	01  w   pic 9.
	01  x   pic 9.
	01  y   pic 9.
	01  z   pic 9.

	procedure division.
	001.
            move 8 to x z
            move 9 to w y

	    add 1 to w
	       size
	       display "overflow on w"
	       
	       add 1 to x
		  not size
                  display "no overflow on x"

		  add 1 to y
		     size
		     display "overflow on y"

		     add 1 to z
			 not size
                         display "no overflow on z"
			 display "right association is sufficient"

			 size
			 display "oops - unexpected result"

		     not size
		     display "oops - unexpected result"

		  size
		  display "oops - unexpected result"
	    
	       not size
               display "oops - unexpected result"
	   
	    end-add
	    
	    . 





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