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

Re: gnubol: A question



Randaall Bart wrote:
> At 04:44 PM 11/1/99 , Michael McKernan wrote:
> >for Randall Bart or whomever might have a defensible opinion.
> 
> Am I supposed to be flattered (I'm the person you ask for by name) or 
> insulted (you think my opinions are indefensible).  B^)
>
If you are flattered that I think you will try to answer my question rather
than offer me your opinion about the programmer who wrote this, then you may
feel flattered.  
 
> >I'm looking at how we might resolve the syntactic ambiguity of
> >abbreviated conditionals and condition names at parse time rather
> >than later in he compilation.
> 
> I think the compilers I worked on parsed the expression as though the 
> abbreviated conditions were booleans and unary operators, then fixed up the 
> expression in the back end.
> 
That's what I've done too.  I want to push pccts a bit this time to see if
it can be persuaded to get through this at parse time.  It would be a matter
of diverting the output of the condition-name parse such that it could be 
available at the reference.  No promises.

> >If I encounter the following
> >         IF a = b OR ( c < d AND e < f ) OR g
> >and "g" is indeed a simple variable, should I interpret this to mean
> >         IF a = b OR ( c < d AND e < f ) OR e < g
> 
> Correct, odd as it seems.
>
Perfect.  I've gotten all three answers.  Do you happen to know if this is
the interpretation found in the defacto standards as well, ie IBM mainframe 
and MicroFocus?

> Whoever writes this code should pay attention the demands of COBOL-20XX 
> with BOOLEAN fields.  BOOLEAN means bit field; what is called boolean in 
> other languages is called conditional.  However, single bit BOOLEANs are 
> interpreted as conditionals.  If g is a single bit BOOLEAN, then it's a 
> conditional and there is no abbreviated condition.  If a is a BOOLEAN 
> (single or multi-bit) then it can't be an abbreviated condition, so it's a 
> syntax error if g isn't a conditional or one bit BOOLEAN.
>
That seems a lesser problem for the compiler; the syntax doesn't change at
all and the semantics are conventional, if new to COBOL.

Many thanks.
 
> --
> RB |\  Randall Bart
> aa |/  Barticus@usa.net 818-985-3259 Barticus@att.net
> nr |\  8321 Burnet Av #1, North Hills, CA 91343
> dt ||\
> a   |/ Y2K website:    http://users.aol.com/PanicYr00
> l   |\
> l   |/ DOT-HS-808-065     I Love You    MS^7=6/28/107
> 
> 
> --
> 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.
> 



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