On Saturday, 2 August 2014 at 04:40:53 UTC, Tofu Ninja wrote:
I don't know... maybe I can try to explain what he is trying to
say.
Correct me if I am wrong in either of your interpretations of
assert.
Your claim is that an assertion is a promise, by the person
asserting, that something is always true. Meaning if you assert
something, the compiler will interpret it to always be true. In
essence the compiler will interpret your promise(as the
programmer) as a never changing fact that can be used for
optimizations.
Actually, I'm going to clarify this: Your assertion is *not* the
promise. Your assertion is simply a statement of fact (note, that
does not mean it's a fact, as that appears to be a point of
confusion: a statement of fact is simply a statement that *can*
be verified). An intrinsic part of programming is that whatever
you write is what you intend to write (that is, it must assume
that you aren't incorrect because it otherwise couldn't compile
the program ... or it'd have to ask you for every line to "sign
off" that it's what you intended). The obvious conclusion is that
you must "promise" that you know what you're doing.
As the human and good programmer, it seems that you wouldn't want
to assume you're correct, but the compiler/programming language
itself has no option but to assume you meant an if statement
there or a function call here, and that you intended these
particular arguments to be passed in this particular order. It
also assume your assertions are what you meant them to be. The
fact that they are checked is a bonus feature (which is really
where the confusion behind assertions lies, as it was for me...
I, like you, thought that assertions MUST be verified and
checked, but that turns out to not be what that meant at all).
His claim is that an assertion is a claim by the person
asserting. That claim has not been proven to be true or false.
Meaning that as a claim, the compiler can't do anything with
that
information alone. The compiler can try to check if the claim is
true and if it is, use that information to optimize. But if it
is
not checked it is merely a claim with no backing, and as such,
nothing can be done with it.
Of course, I can understand that interpretation. But at the same
time, why would you write something and expect a compiler to do
nothing with it? Is there any other construct in the language
that does that? Even noops in ASM which literally mean "do
nothing" actually have an effect on the intended meaning of a
program.
...
Ok that was my interpretation of both of your interpretations. I
hope I didn't misinterpret.
Personally I side with the argument that assert is a claim which
I believe is closer to the actual meaning of the word assert and
closer to how programmers use assert now.
If you look at the google definition of assert...
"state a fact or belief confidently and forcefully."
You will see that it says an assertion is a statement of a "fact
or belief". The "confidently and forcefully" portion of the
definition is just describing the attitude of the asserter, so
in
this context is not relevant. That means that the speaker can
use
an assertion to state either a fact or a belief(I think in this
context a belief is sufficiently close to a claim, both could be
true or false). As the person being spoken to, there is no way
to
know if the speaker is asserting a fact or a belief. This means
that as the person being spoken to, you have no choice but to
come to the conclusion that what is being asserted could be
either of the two and thus could either be true or false.
In the context of a programmer and a compiler, the programmer is
the speaker and the compiler is the thing being spoken to. This
means that if the programmer asserts something the compiler has
no choice but to interpret what is being asserted could either
be
true or false.
Now you could say that the compiler implicitly trusts the
programmer and as such takes all assertions as fact, but I
believe that is a mistake on the compilers part. If the compiler
implicitly trusted the programmer, there would be no warnings,
and type checking ... ect. You could say that the compiler only
implicitly trusts the programmer in the case of assert, but I
still believe this to be a mistake on the compilers part.
I see it the exact opposite way. I see it as the compiler is
helpful and will do as much proving as it can, but ultimately it
must always logically put if statements in where you want them
and function calls in where you want them. Technically, it takes
some liberties with optimizations because it has good reason to
believe that the two interpretations are equivalent. That said,
when we pass `-O` to the compiler, we're commanding it to do
that... so... *shrug*
Thus when you assert something is true and the compiler can't
immediately disprove you, it must follow what you say. FWIW, I
feel that something like this should fail compilations:
```
int x = 1;
assert(x != 1);
```
because the compiler could, in fact, disprove you at compile
time. That said, it's not a scalable approach because there
exists too many programs that you cannot prove the output of.
Otherwise, if it can't immediately disprove what you say (by type
checking, for instance), then it has no choice but to do what you
say, even if you're wrong. Even if you do `x1 == x2 && y1 == x2`
in a conditional somewhere, it can't/won't take liberties to
"correct it" to `x1 == x2 && y1 == y2`. But if x1 is a
FloatMeters and x2 is a FloatMiles, I would expect it to disprove
that it's a correct comparison (unless you make statements
suggesting that this is what you really mean, of course). But
then again, I refer to the above where obviously illogical things
should fail to compile as well. But once it compiles, I expect
that it does what I say even if what I say is wrong.
