Re: next "big" language?? (disagree)

[dewar@cs.nyu.edu (Robert Dewar)]

Fergus said:

"But it *does* affect the behaviour!

Are the people who want this model asking for the impossible?"

Maybe I was not clear enough, because at least informally, it is easy 
enough to understand what is wanted.

The word behavior was confusing in my original note, because I was
talking about the behavior of the compiler, not the behavior of the
program.

What is wanted is that the code generated not be affected by the presence
of assert, so you can stick in asserts without affecting the code. Now that's
a little bit of a self-contradiction, since obviously there is code for the
assert itself if it is turned on, so more accurately (and this is why it is
hard to characterize this requirement), the requirement is to minimize the
effect on the generated code.

For example, suppose we write:

     x := y / z;

and we get a divide by zero error from the generated code. Now there are
two reasons for this. Either z is zero, or there is something wrong with
the generated code. Now suppose we add an assertion:

     pragma Assert (z /= 0);
     x := y / z;

and we run the code and this time get no error. Well that's confusing. The
probably explanation is that the assert is intefering and changing the
generated code. In particular, the most likely cause of getting no error is
that indeed z is non-zero, and that the compiler now generates different
(correct) code for the division, omitting the faulty check for a zero
divisor.

If your assert is non-intrusive according to the definition (or rather
informal description) above, then you will get a division by zero error
at the divide, even though the assertion does not fail.

Well that's still a puzzle, but leaves things clearer. Note that we are
not necessarily talking about improper code generation from the compiler,
erroneous programs can cause this difficulty. For example, suppose the
definition of z is:

  z : integer range 1 .. 10;

now the compiler can legitimately use 32 bits to represent z, but it can
also legitimately assume that the value is in the range 1 .. 10.

It would therefore be fine for the assert to check only the low order 8 bits
of the 32 bits, and the divide to use all 32 bits. This would result in the
anomolous behavior perceived.

(in the case where z was in fact uninitialized or otherwise abnormal)

The notion of the non-intrusive assert ("please compiler, don't try to
figure out things from the assert, compile it in isolation and do not
let it affect other code") is particularly valuable in the presence of
errors in the compiler code generator, or in the case of erroneous
programs. In either case, the additional deductions the compiler does
from the assert (which of course might even be wrong themselves) can
make it harder to figure out what is going on.

I hope this is clear enough to understand this point of view. One thing
for sure is that it is essential to understand all three points of view
before starting off to design language features in this area. I am not
saying you have to agree with all points of view, but you definitely
have to make the effort to fully understand them.