GNAT messages and the not operator (pitfall alert!)

GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

Here is an entertaining little bit of error message stuff in GNAT. Someone
submitted the following program, shown with its original message:

     1. procedure t is
     2. begin
     3.     if not 7 < 5 then
               |
        >>> no modular type available in this context

     4.         null;
     5.     end if;
     6. end;

Well, that error message is "correct", the expression "not 7" cannot
be resolved. But it sure is confusing. The latest version of GNAT (3.08)
gives:
     1. procedure t is
     2. begin
     3.     if not 7 < 5 then
                   |
        >>> operand of not must be enclosed in parentheses

     4.         null;
     5.     end if;
     6.
     7.     if (not 7) < 5 then
                |
        >>> no modular type available in this context

     8.         null;
     9.     end if;
    10.
    11. end;

I have added the parenthesized case here to make sure we do the right thing!

Now, a worse case, suppose that we *are* dealing with modular types, well
then the extension of Ada 95 to allow not on such types has added a real
pitfall to the language. Ada does not have many pitfalls. I mean by pitfall
a case where you write something that looks reasonable, is legal and executes
but does something completely different from what you expect (e.g. in
C the case of if ("abc"=="abc") yielding false).

Consider this program, which we now, as you see, generate a warning for:

     1. with Text_IO; use Text_IO;
     2. procedure t1 is
     3.    type m is mod 256;
     4.    a : m := 4;
     5.    b : m := 5;
     6. begin
     7.     if not a < b then
               |
        >>> warning: operand of not operator should be parenthesized

     8.         Put_Line ("this is what I expect");
     9.     else
    10.         Put_Line ("but this is what I get!");
    11.     end if;
    12.
    13.     if (not a) < b then
    14.         Put_Line ("this is not what I expect");
    15.     else
    16.         Put_Line ("this is what I get, and I really asked for it!");
    17.     end if;
    18. end;

I think this warning is quite reasonable, since I would *really* like people
to use parens if they really want the situation shown on line 13!

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

Here is another pitfall, pretty horrible if it hits, but fortunately rare.
Ask an Ada expert what is the value of

    -5 mod 3

Almost anyone (the better they know Ada, the more likely they are to make
this mistake) will strain to remember the table in the RM that talks about
negative mods, and, if they remember it right, come up with the answer of 1.
But Ada has VERY odd precedence rules which mean that the default
parenthesiztion of this expression is -(5 mod 3). The only person I
ever knew to get this right (and remember this is under conditions they
know they are being asked to answer a trick question) was Robert Eachus
(both Jean and Tuck got this wrong originally, and so did I :-)

A rare error, since this is unusual usage, but still it seems worth another
warning (incidentally, try these programs on your own compiler and see what
it does -- versions of GNAT before 3.08 are not much help, how do other
compilers do :-)

Incidentally, this is not a zero probability occurrence, we actually had
someone run into this bug recently! Here is the output of GNAT 3.08 on
an example program:

     1. with Text_IO; use Text_IO;
     2. procedure t2 is
     3.    a : integer := 5;
     4.    b : integer := 3;
     5.
     6. begin
     7.    if -5 mod 3 /= 1 then
              |
        >>> warning: unary minus expression should be parenthesized here

     8.       Put_Line ("Table in RM for negative mods is screwed up");
     9.    end if;
    10.
    11.    if (-5) mod 3 /= 1 then
    12.       null;
    13.    else
    14.       Put_Line ("No it isn't!");
    15.    end if;
    16. end;

Re: GNAT messages and the not operator (pitfall alert!)

[whiting_ms@corning.com (Matt Whiting)]

In article <dewar.846163972@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Here is another pitfall, pretty horrible if it hits, but fortunately rare.
> Ask an Ada expert what is the value of
> 
>     -5 mod 3
> 
> Almost anyone (the better they know Ada, the more likely they are to make
> this mistake) will strain to remember the table in the RM that talks about
> negative mods, and, if they remember it right, come up with the answer of 1.
> But Ada has VERY odd precedence rules which mean that the default
> parenthesiztion of this expression is -(5 mod 3). The only person I
> ever knew to get this right (and remember this is under conditions they
> know they are being asked to answer a trick question) was Robert Eachus
> (both Jean and Tuck got this wrong originally, and so did I :-)

I'm really confused now.  How does -(5 mod 3) yield 1?  I thought 5 mod 3 would
evaluate to 2 and then the unary minus would yield -2.  Will someone provide a
play-by-play evaluation sequence for this expression?

Matt

Re: GNAT messages and the not operator (pitfall alert!)

[David C. Hoos, Sr.]

whiting_ms@corning.com (Matt Whiting) wrote in article
<1996Oct25.103321.1@corning.com>...
> In article <dewar.846163972@merv>, dewar@merv.cs.nyu.edu (Robert Dewar)
writes:
> > Here is another pitfall, pretty horrible if it hits, but fortunately
rare.
> > Ask an Ada expert what is the value of
> > 
> >     -5 mod 3
> > 
> > Almost anyone (the better they know Ada, the more likely they are to
make
> > this mistake) will strain to remember the table in the RM that talks
about
> > negative mods, and, if they remember it right, come up with the answer
of 1.
> > But Ada has VERY odd precedence rules which mean that the default
> > parenthesiztion of this expression is -(5 mod 3). The only person I
> > ever knew to get this right (and remember this is under conditions they
> > know they are being asked to answer a trick question) was Robert Eachus
> > (both Jean and Tuck got this wrong originally, and so did I :-)
> 
> I'm really confused now.  How does -(5 mod 3) yield 1?  I thought 5 mod 3
would
> evaluate to 2 and then the unary minus would yield -2.  Will someone
provide a
> play-by-play evaluation sequence for this expression?
> 
> Matt
> 
Hi Matt,
I think the problem is that you didn't read Robert's English very
carefully.  It might have been better had he said "....and, if they
remember it right, come up with the (wrong) answer of 1."

In other words, (-5) mod 3 = 1, and -(5 mod 3) = 2
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

iMatt, I said

"> Almost anyone (the better they know Ada, the more likely they are to make
> this mistake) will strain to remember the table in the RM that talks about
> negative mods, and, if they remember it right, come up with the answer of 1."


I did not say that 1 was the right answer, in fact the whole point of the
post is that -5 mod 3 has nothing to do with the table in the RM about
negative mods, since this is a simple positive mod, so the answer from
the table is wrong!!!!!!

Re: GNAT messages and the not operator (pitfall alert!)

[Matthew S. Whiting]

Robert Dewar wrote:
>  
> I did not say that 1 was the right answer, in fact the whole point of the
> post is that -5 mod 3 has nothing to do with the table in the RM about
> negative mods, since this is a simple positive mod, so the answer from
> the table is wrong!!!!!!

OK, so I didn't know enough about the RM to to catch the sublety of your point...
I hate it when that happens!

Matt

Re: GNAT messages and the not operator (pitfall alert!)

[John Herro]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Ask an Ada expert what is the value of
>    -5 mod 3
> Almost anyone [gets it wrong] ... the default
> parenthesiztion of this expression is -(5 mod 3).

This brings us to a coding style rule that I wish everyone would follow. 
Use parentheses unless the order of evaluaton is VERY OBVIOUS.  A person
reading your code should _never_ have to go to the RM to look up the
precedence of operators, and certainly you should never refer to that
section when writing code; use parentheses instead.

I'm not saying that the code

   if X**2 + 3.0*X + 2.0 < 100.0 then ...

should be cluttered with unnecessary parentheses.  Everyone knows that
"**" comes before "*" and "/", which come before binary "+" and "-", and
everyone knows that the relational operators have a low precedence.  It's
also arguable that "everyone" knows that "and" comes before "or".  But I'd
say in almost every other case, unless the order of evaluation is very
obvious, use parentheses!

Even Ada has some pitfalls.  If everyone followed this rule, one of them
would be no problem.

- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor

Re: GNAT messages and the not operator (pitfall alert!)

[Matthew Heaney]

In article <54snn6$8j5@newsbf02.news.aol.com>, johnherro@aol.com (John
Herro) wrote:

>It's also arguable that "everyone" knows that "and" comes before "or".

Are you sure?  My understanding is that "and" and "or" have equal
precedence, and that Ada *requires* the use of parens to force to
programmer to state his intent.

The Ada 83 explains that because we've all been taught algebraic logic
since we were young whipper-snappers, the precedence of "+" and "*" is
well-kwown.  But because we haven't all been taught relational logic that
long, there's some potential ambiguity.  So Ada eliminates it once and for
all by forcing the use parens.

The thing I'd like to add, however, is to admonish programmers to not to
write complicated predicates!  If you're writing a predicate that requires
the use of "a lot of" parens, then try to re-think your solution.  As has
been noted in this group before, one of the largest sources of errors
(perhaps _the_ largest) is predicates, especially getting loop termination
correct.

Please, please, if you need to leave a loop early, then use "exit when..." 
or return.  I've often seen code (even in software engineering texts that
use Ada examples) that sets a loop flag to false, that in turn gets tested
at the top of the (while) loop.  This is clearly a misuse of the language
and a violation of all the principles of programming as a _human_ activity,
as you've just doubled the number of states you have to test!

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

Matthew said

  Are you sure?  My understanding is that "and" and "or" have equal
  precedence, and that Ada *requires* the use of parens to force to
  programmer to state his intent.

Well I can't really see what sense it makes to say they have the same
precedence when they cannot be mixed, but yes indeed, parens are
required.

  Please, please, if you need to leave a loop early, then use "exit when..."
  or return.  I've often seen code (even in software engineering texts that
  use Ada examples) that sets a loop flag to false, that in turn gets tested
  at the top of the (while) loop.  This is clearly a misuse of the language
  and a violation of all the principles of programming as a _human_ activity,
  as you've just doubled the number of states you have to test!

This is an arguable point. A loop with a goto that terminates it early (an
exit is a form of goto), has the disadvantage that there is no clear
precondition for the loop. I am not necessarily disagreeing, just saying
that this is a trickier issue that you suggest.

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

iJohn Herro says

"should be cluttered with unnecessary parentheses.  Everyone knows that
"**" comes before "*" and "/", which come before binary "+" and "-", and
everyone knows that the relational operators have a low precedence.  It's
also arguable that "everyone" knows that "and" comes before "or".  But I'd
say in almost every other case, unless the order of evaluation is very
obvious, use parentheses!"


Well I am never sure what "everyone knows", but if everyone using Ada knows
that "and" comes before "or", they are mistaken! The syntactic rules of
Ada REQUIRE parenthesization for mixed logical operators. I guess John
never made this argument in his own Ada code, which is why he was unaware
of this rule (which is an old Ada 83 rule).

As for always using parens, yes, everyone agrees with this rule (after
all there are very few levels of precendece in Ada anyway, John's rule
is more the kind of rule that is useful in a C environment than Ada
anyway). The trouble is that one of the other things that "everyone knows"
is that unary operators have higher precedence than binary operators, because
this is true in every other language than Ada as far as I know, and

    -a mod b

reads wrong naturally to almost everyone. It is a bad mistake in a language
to violate these rules that "everyone knows". In Ada it happened from
a kind of accidental by product of keeping the number of precedence
levels low. In fact it is VERY rarely a problem, because it is only mod
that has a problem (for every other binary operator, the minus distributes
in any case, so the precedence is unimportant), and taking mod of negative
numbers is rare, and using an explicit minus to negate the left operand
even rarer.

I well remember another case like this in SNOBOL4. In an attempt to 
duplicate normal mathematical notation more closely, where division
is represented by a low precedence horizontal line, Ralph Griswold
decided to make division have lower precedence than multiplication,
so that

    A*B / C*D

means what it looks like. Well I remember once spending quite a bit
of time puzzling over why SPITBOL was generating the "wrong code",
when in fact it was completely right, just following this unusual
rule.

I wonder if anyone ever suggested using spacing to wonder about
precedence (I am not suggesting it, it is not a good idea, however,
it gives me an idea, if a programmer uses spacing, as in the above
example of A*B / C*D in a manner that is clearly at odds with the
precedence, then perhaps a warning is a good idea?)

Re: GNAT messages and the not operator (pitfall alert!)

[John Herro]

dewar@merv.cs.nyu.edu (Robert Dewar)
corrects my error, writing that Ada
requires parentheses when mixing
"and" and "or" in an expression.

I'm surprised, but of course you're right!  I was thinking of mentioning
this in the "Loose Ends and Pitfalls" section of my AdaTutor program, but
then decided against it.  If a person writes A and B or C, the compiler
will complain, so that's not really a pitfall, just a possible surprise..

Fortunately, the tutorial _does_ already list as a pitfall the fact that
-A mod B means -(A mod B).

- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor
-----
The mathematical relationship between Christmas and Halloween:
31     =  25
  OCT       DEC

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

iJohn Herro saoid

"Fortunately, the tutorial _does_ already list as a pitfall the fact that
-A mod B means -(A mod B)."

I don't know if this is fortunate or not, the likelihood of this information
being usful for anything but answering trick questions is low :-)

As for it being a surprise that a and b or x is not accepted, I don't really
think so. People can always be surprised if they don't know things, but
this is a very familiar rule, and the error msg you get if you violate it
will be clear enough.

Re: GNAT messages and the not operator (pitfall alert!)

[Dr. Peter E. Obermayer]

John Herro wrote:

-- Discussion on parntheses deleted

> I'm not saying that the code
> 
>    if X**2 + 3.0*X + 2.0 < 100.0 then ...

Better (X + 3.0)*X + 2.0 < 100.0

> 
> should be cluttered with unnecessary parentheses.  Everyone knows that
> "**" comes before "*" and "/", which come before binary "+" and "-", and
> everyone knows that the relational operators have a low precedence.  It's
> also arguable that "everyone" knows that "and" comes before "or".  But I'd
> say in almost every other case, unless the order of evaluation is very
> obvious, use parentheses!
> 
> Even Ada has some pitfalls.  If everyone followed this rule, one of them
> would be no problem.
> 
> - John Herro
> Software Innovations Technology
> http://members.aol.com/AdaTutor
> ftp://members.aol.com/AdaTutor


Peter E. Obermayer

   _/_/_/ _/_/_/ _/_/_/ Dr. Peter E. Obermayer 
  _/     _/       _/                           Tel.:   xx49(5931)805-469
 _/     _/       _/     Lohberg 10             Fax:    xx49(5931)842-469
_/_/_/ _/_/_/ _/_/_/    D-49716 Meppen         e-mail: obermayer@cci.de

Re: GNAT messages and the not operator (pitfall alert!)

[John Herro]

I wrote:
> if X**2 + 3.0*X + 2.0 < 100.0 then ...

"Dr. Peter E. Obermayer" <obermaye@cci.de> wrote:
> Better (X + 3.0)*X + 2.0 < 100.0

Agreed.  And if you have a higher degree polynomial to compute, there's
even more reason, from the standpoint of efficiency, to use successive
addition and multiplication (with nested parentheses), rather than raising
X to several different powers.

Mine was just an artificial example of an expression that doesn't need
parentheses to clarify.  One COULD argue that the less efficient
expression is a little easier to read than the more efficient one, but I
don't think the difference in readability is very great.

- John Herro
Software Innovations Technology
http://members.aol.com/AdaTutor
ftp://members.aol.com/AdaTutor
-----
ANSWER: J.C. Penney
QUESTION: Give the initials of the President who authorized the Susan B.
Anthony dollar, and its approximate worth on the international market.

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

John Herro said

"Agreed.  And if you have a higher degree polynomial to compute, there's
even more reason, from the standpoint of efficiency, to use successive
addition and multiplication (with nested parentheses), rather than raising
X to several different powers."


from the standpoint of efficiency yes, but not neccessarily from the
point of view of accuracy. The model interval of the factored form
can be wider than the model interval of the non-factored form
(e.g. x*x*x*x may well have a narrower model interval than (x**2)**2,
evn though the latter does fewer operations.

Re: User Password expiration date extractor?

[Stein-Aksel Basma]

John Herro said

"Agreed.  And if you have a higher degree polynomial to compute, there's
even more reason, from the standpoint of efficiency, to use successive
addition and multiplication (with nested parentheses), rather than raising
X to several different powers."


from the standpoint of efficiency yes, but not neccessarily from the
point of view of accuracy. The model interval of the factored form
can be wider than the model interval of the non-factored form
(e.g. x*x*x*x may well have a narrower model interval than (x**2)**2,
evn though the latter does fewer operations.

Re: GNAT messages and the not operator (pitfall alert!)

[Norman H. Cohen]

Robert Dewar wrote:
> 
> Here is another pitfall, pretty horrible if it hits, but fortunately rare.
> Ask an Ada expert what is the value of
> 
>     -5 mod 3

I agree this is a nasty one, and Ada as a Second Language explicitly
warns about it (bottom of page 245), as well as about the only slightly
less insidious

   A+B mod C

(which means A + (B mod C)).  However, the 

   not A > B

case is less troubling to me, because each relational operator and
membership test has a complement, and a programmer is far more likely to
write "A <= B" rather than "not A < B" if he means "not (A < B)".  (Yes,
I know ">" might be overloaded with some partial ordering so that A<=B
and A>B are both false, but that is hardly the typical case!)  Also, as
Robert pointed out, this case (unlike the mod case) will usually
manifest itself as a type mismatch.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: GNAT messages and the not operator (pitfall alert!)

[whiting_ms@corning.com (Matt Whiting)]

In article <32762A30.D2D@watson.ibm.com>, "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
> Robert Dewar wrote:
>> 
>> Here is another pitfall, pretty horrible if it hits, but fortunately rare.
>> Ask an Ada expert what is the value of
>> 
>>     -5 mod 3
> 
> I agree this is a nasty one, and Ada as a Second Language explicitly
> warns about it (bottom of page 245), as well as about the only slightly
> less insidious

Relative to the page 245 warning and the table on page 246, I'm still confused.
I'm probably beating a dead horse here, but something still doesn't seem right.
If I'm reading the p. 246 table correctly, -5 mod 4 (row 1, column 4, excluding
the "header row and column"), should evaluate to 3.  However, I just wrote a
simple little program using ObjectAda V7.0 which evaluates to -1, which, BTW,
is what I would have expected.  Taking into account the warning on p. 245, I
also tried -(5 mod 4).  It does give the identical -1 result.  Am I reading the
table incorrectly?

Matt

Re: GNAT messages and the not operator (pitfall alert!)

[David C. Hoos, Sr.]

whiting_ms@corning.com (Matt Whiting) wrote in article
<1996Oct29.145959.1@corning.com>...
> In article <32762A30.D2D@watson.ibm.com>, "Norman H. Cohen"
<ncohen@watson.ibm.com> writes:
> > Robert Dewar wrote:
> >> 
> >> Here is another pitfall, pretty horrible if it hits, but fortunately
rare.
> >> Ask an Ada expert what is the value of
> >> 
> >>     -5 mod 3
> > 
> > I agree this is a nasty one, and Ada as a Second Language explicitly
> > warns about it (bottom of page 245), as well as about the only slightly
> > less insidious
> 
> Relative to the page 245 warning and the table on page 246, I'm still
confused.
> I'm probably beating a dead horse here, but something still doesn't seem
right.
> If I'm reading the p. 246 table correctly, -5 mod 4 (row 1, column 4,
excluding
> the "header row and column"), should evaluate to 3.  However, I just
wrote a
> simple little program using ObjectAda V7.0 which evaluates to -1, which,
BTW,
> is what I would have expected.  Taking into account the warning on p.
245, I
> also tried -(5 mod 4).  It does give the identical -1 result.  Am I
reading the
> table incorrectly?
> 
> Matt
> 
-5 mod 4 = -(5 mod 4) = -1, but (-5) mod 4 = 3

Is it clear now?
-- 
David C. Hoos, Sr.,
http://www.dbhwww.com
http://www.ada95.com

Re: GNAT messages and the not operator (pitfall alert!)

[whiting_ms@corning.com (Matt Whiting)]

In article <01bbc5fe$823691c0$308371a5@dhoossr.iquest.com>, "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
> whiting_ms@corning.com (Matt Whiting) wrote in article
> <1996Oct29.145959.1@corning.com>...
>> 
>> Relative to the page 245 warning and the table on page 246, I'm still
> confused.
>> I'm probably beating a dead horse here, but something still doesn't seem
> right.
>> If I'm reading the p. 246 table correctly, -5 mod 4 (row 1, column 4,
>>excluding
>> the "header row and column"), should evaluate to 3.  However, I just
>> wrote a
>> simple little program using ObjectAda V7.0 which evaluates to -1, which,
>> BTW,
>> is what I would have expected.  Taking into account the warning on p.
>> 245, I
>> also tried -(5 mod 4).  It does give the identical -1 result.  Am I
>> reading the
>> table incorrectly?
>> 
> -5 mod 4 = -(5 mod 4) = -1, but (-5) mod 4 = 3
> 
> Is it clear now?
--

Yes, that is clear (and has been!), but the table on p. 246 of Ada as a Second
Language (2nd Edition), doesn't have parens around the first argument!

When I see X mod 4 and then see the column header have -5, I read that as
-5 mod 4, not as (-5) mod 4.  I think the table could be more clear...  :-)
Had the table read (X) mod 4... 

Matt

Re: GNAT messages and the not operator (pitfall alert!)

[Norman H. Cohen]

whiting_ms@corning.com (Matt Whiting) wrote:

> Yes, that is clear (and has been!), but the table on p. 246 of Ada as a Second
> Language (2nd Edition), doesn't have parens around the first argument!
> 
> When I see X mod 4 and then see the column header have -5, I read that as
> -5 mod 4, not as (-5) mod 4.  I think the table could be more clear...  :-)
> Had the table read (X) mod 4...

By this reasoning, one would expect "A*4 where A=2+3" to mean "2+3*4".

I expect it to be clear to all readers that X in Figure 6.2 represents
an integer value, not a string to be macro-substituted into the string
"X mod 4" to yield the string 
"-5 mod 4".  Rather, the table entry corresponding to the row labeled "X
mod 4" and the column labeled with -5 for the value of X gives the value
that would be written by the statements

   X := -5;
   Put ( X mod 4 );

The caption begins with the words, "Illustrations of the behavior of rem
and mod ...," which ought to make it clear that the focus of the table
is on run-time computations performed on particular values rather than
on syntactic issues like precedence level in the text of the program. 
Indeed, the caption specifically refers to successive "values" of X.

If Matt thinks that (X) conveys anything different from X, perhaps he
has spent too much time working with a C preprocessor. :-)

However, if other readers have misinterpreted the table in the same way
that Matt did, I would certainly like to hear about it!  (Private e-mail
will do, no need to clutter the newsgroup.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: GNAT messages and the not operator (pitfall alert!)

[Norman H. Cohen]

whiting_ms@corning.com (Matt Whiting) wrote (referring to Figure 6.2 in
Ada as a Second Language):

> If I'm reading the p. 246 table correctly, -5 mod 4 (row 1, column 4, excluding
> the "header row and column"), should evaluate to 3.  However, I just wrote a
> simple little program using ObjectAda V7.0 which evaluates to -1, which, BTW,
> is what I would have expected.  Taking into account the warning on p. 245, I
> also tried -(5 mod 4).  It does give the identical -1 result.  Am I reading the
> table incorrectly?

You are indeed reading the table incorrectly.  The entry to which you
refer occurs in the row marked "X mod 4" in the column for X = -5.  Thus
it gives the value for (-5) mod 4, which is indeed 3, not the value of
-(5 mod 4), which is, of course -1.  

(As you noted, "-5 mod 4" means, surprisingly, "-(5 mod 4)", so the
table entry for X mod 4 when X = -5 is NOT the value of -5 mod 4.)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: GNAT messages and the not operator (pitfall alert!)

[Richard A. O'Keefe]

"Norman H. Cohen" <ncohen@watson.ibm.com> writes:

>(As you noted, "-5 mod 4" means, surprisingly, "-(5 mod 4)", so the
>table entry for X mod 4 when X = -5 is NOT the value of -5 mod 4.)

I don't understand what is surprising about -5 mod 4 being the same
as -(5 mod 4).  After all, you expect -x to be the same as 0-x,
and 0 - 5 mod 4 is
	<operand 1> ADD <operand 2> MULTIPLY <operand 3>
which naturally groups as
	<operand 1> ADD (<operand 2> MULTIPLY <operand 3>)

The grouping, at least, is identical in Pascal.
-- 
Mixed Member Proportional---a *great* way to vote!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: GNAT messages and the not operator (pitfall alert!)

[Norman H. Cohen]

Richard A. O'Keefe wrote:
 
> "Norman H. Cohen" <ncohen@watson.ibm.com> writes:
> 
> >(As you noted, "-5 mod 4" means, surprisingly, "-(5 mod 4)", so the
> >table entry for X mod 4 when X = -5 is NOT the value of -5 mod 4.)
> 
> I don't understand what is surprising about -5 mod 4 being the same
> as -(5 mod 4).  After all, you expect -x to be the same as 0-x,
> and 0 - 5 mod 4 is
>         <operand 1> ADD <operand 2> MULTIPLY <operand 3>
> which naturally groups as
>         <operand 1> ADD (<operand 2> MULTIPLY <operand 3>)
> 
> The grouping, at least, is identical in Pascal.

This is a fine explanation of why, according to the language rules, -5
mod 4 does indeed mean -(5 mod 4).  However, whether or not this is
"surprising" is a psychological issue, not an issue of
programming-language rules.

I suppose you could argue that if -(5 mod 4) is the interpretation that
follows from the language rules, nobody able to read the reference
manual should be "surprised" by it.  Nonetheless, the fact is that many
Ada experts, including the designer of the language, *were* fooled by an
expression of this form.  It's not that they didn't understand the
precedence rules--if you had asked straight out whether -5 mod 4 means
    (-5) mod 4
or
    -(5 mod 4), 
all would have answered correctly.  However, when asked 
   "What is the value of -5 mod 4"?, 
they assumed that this was a question about the semantics of mod for
negative operands rather than a question about precedence rules, since
interesting questions are more often questions of semantics rather than
syntax, and familiarity with the behavior of rem and mod for negative
operands is a good litmus test of Ada expertise.  Thus distracted from
questions of precedence, they intuitively interpreted the expression
incorrectly.  Whatever the language rules say, the brain apparently
tends to see a unary minus as binding more tightly than a word
surrounded by spaces.  Perhaps writing
   - 5 mod 4
(with a space after the minus) would ameliorate this effect somewhat,
but the best advice to a programmer writing this expression is to use
parentheses--
   -(5 mod 4)
--even though they are technically unnecessary.  After all, one should
not assume that whoever is going to read the program is less easily
fooled than Jean Ichbiah and the other experts who answered incorrectly.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

Norman Cohen says

"they assumed that this was a question about the semantics of mod for
negative operands rather than a question about precedence rules, since
interesting questions are more often questions of semantics rather than
syntax, and familiarity with the behavior of rem and mod for negative
operands is a good litmus test of Ada expertise.  Thus distracted from
questions of precedence, they intuitively interpreted the expression
incorrectly.  Whatever the language rules say, the brain apparently
tends to see a unary minus as binding more tightly than a word
surrounded by spaces.  Perhaps writing"

   I think that misses the point, there are two other reasons why
   -5 mod 4 looks like (-5) mod 4 to most people:

   1. Almost all other languages give unary operators higher precedence

   2. People think of -5 as a negative literal, even though it is not.
      Most of the time, you can't tell the difference, and if unary
      operators have higher precedence than any binary operator, then
      this is even more true (a very good reason for making unary
      operators have higher precedence, one that for some reason got
      ignored in the Ada design.

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

iMatt asks

"Relative to the page 245 warning and the table on page 246, I'm still confused.
I'm probably beating a dead horse here, but something still doesn't seem right.
If I'm reading the p. 246 table correctly, -5 mod 4 (row 1, column 4, excluding
the "header row and column"), should evaluate to 3.  However, I just wrote a
simple little program using ObjectAda V7.0 which evaluates to -1, which, BTW,
is what I would have expected.  Taking into account the warning on p. 245, I
also tried -(5 mod 4).  It does give the identical -1 result.  Am I reading the
table incorrectly?"

Yes, you are beating a dead horse :-)

The table does not tell you what happens if you write -5 mod 4 , it tells
you the result of the mod operation if the left operand is -5 and the 
right operand is 4. The WHOLE POINT OF THE ORIGINAL POST is that these
are different!

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

Norman said

"I agree this is a nasty one, and Ada as a Second Language explicitly
warns about it (bottom of page 245), as well as about the only slightly
less insidious

   A+B mod C

(which means A + (B mod C))."

I find that completely dubious, apart from the spacing (which would be
a factor even in A+B * C), it seems clear that one expects mod to have
a similar precedence to multiplication or division.

Re: GNAT messages and the not operator (pitfall alert!)

[Cary Jamison]

Robert Dewar wrote:
[...]
RD> Consider this program, which we now, as you see, generate a warning for:
RD> 
RD>      1. with Text_IO; use Text_IO;
RD>      2. procedure t1 is
RD>      3.    type m is mod 256;
RD>      4.    a : m := 4;
RD>      5.    b : m := 5;
RD>      6. begin
RD>      7.     if not a < b then
RD>                |
RD>         >>> warning: operand of not operator should be parenthesized
RD> 
RD>      8.         Put_Line ("this is what I expect");
RD>      9.     else
RD>     10.         Put_Line ("but this is what I get!");
RD>     11.     end if;
RD>     12.
RD>     13.     if (not a) < b then
RD>     14.         Put_Line ("this is not what I expect");
RD>     15.     else
RD>     16.         Put_Line ("this is what I get, and I really asked for it!");
RD>     17.     end if;
RD>     18. end;
RD> 
RD> I think this warning is quite reasonable, since I would *really* like people
RD> to use parens if they really want the situation shown on line 13!

But, shouldn't the warning be "not expression should be parenthesized"?  I think
the "operand of not operator" would just be the 7, i.e. "not (7)" instead of "(not 7)".


-- 
Cary Jamison
TRW SIG
cary@svl.trw.com

Re: GNAT messages and the not operator (pitfall alert!)

[Robert Dewar]

iCary says

"But, shouldn't the warning be "not expression should be parenthesized"?"

In fact that *is* what the message says in the latest version of GNAT. I
already changed this.