On Saturday, 2 August 2014 at 06:08:43 UTC, Tofu Ninja wrote:
On Saturday, 2 August 2014 at 05:07:58 UTC, Chris Cain wrote:
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).
I am going to have to disagree, I think what you are calling a
statement of fact, is actually a claim. A statement is simply a
piece of communication. So if you state a belief, you are simply
communicating that belief's existence. So a statement of fact is
simply the communication that the fact exists.
Well, you can disagree but it doesn't change the fact that what I
meant and what you're saying are two different things. With this
knowledge you can now infer that you are putting forth effort to
intentionally misunderstand me despite me trying to clarify that
there is a difference, which isn't productive.
In reality you can never actually state a fact because you can
only ever believe a fact is true. It comes down to the
philosophical problem of "I think therefore I am", which
basically says that the only thing that your mind can PROVE 100%
is that you are thinking.
You can state a belief, but to anyone else hearing that
statement, it will be a claim. Basicly is comes down to this...
*A claim is something that can be true or false
*A belief is a claim that is true in the believer's mind, but if
stated becomes a claim due to that possibility that the
believer's is in error
*A fact is something that is always true
That is why you can have true statements and false statements,
it
is not that the statement is self is true or false, but that the
claim that is being stated is true or false.
Frankly, it seems we've regressed back to making up definitions
for words and phrases that are well-defined and those
well-defined meanings contradict what you're trying to suggest.
That's not going to help you understand why I think assert makes
sense given the real definition of an assertion.
It is not a matter of the compiler trying to determine if you
meant to write what you did or not(there is no way it can). It
is
a matter of the compiler determining if what you wrote is what
it
considers to be correct input. If you try to compile
"SDA@#$!$SDF#$T#", the compiler has no way of knowing if you
meant to write that or not, but it is still allowed to reject
that.
Of course, but it must reject that because it couldn't possibly
understand that. Furthermore, most of the things in compilers
that are disprovable at compile time are disproven at compile
time. Those things which cannot be disproven at compile time
(see: halting problem) cannot be rejected. Hence, if statements
and asserts, and why type-check failures result in a failed
compilation.
Because if the compiler actually checks the claim then it can
optimize on it, but if the compiler does not check then it can
not know its true and can not optimize.
But it doesn't need to check because that's not what assert means
to do. You're focusing too much on the "checking" part which has
nothing to do with the actual English definition of assert (which
is my point for why it makes sense for assert to do what it
does). A runtime check is a "nice thing to have" (it makes
asserts more useful, ultimately), but it seems completely
orthogonal to what assert means in this case considering the
definition of assert.
I think a point that needs to be addressed is that there is a
difference between a program being defined incorrectly and a
program being undefined.
If the programmer defines his program incorrectly, then yes, you
are correct in that the compiler has no choice but to still take
the incorrect definition.
The program is still defined in a way the compiler understands,
its just not what the programmer was trying to say.
But, if a program is undefined, then the compiler does not know
what to do, which in how compilers are implemented means the
compiler can literally do anything it wants.
Typing "while" instead of "if" might be an incorrect definition
of the program that the programer was trying to create, but is
is
still a valid program definition(just not the one the programmer
wanted).
On the other hand, having contradicting asserts(with your
interpretation of assert) is not an incorrectly defined program,
but an undefined program because it simply does not make sense.
OK, but I see these as being much more similar conceptually than
you're giving them credit. Despite "undefined behavior" occurring
when an assertion fails, it doesn't actually mean that you can't
reason about what can occur, just that there's no required
definition for what will occur (that's why it's called
"undefined"). That is the two interpretations of a D program are
accepted by the spec:
```
assert(x != 1);
//... code that doesn't have any effect on x
if(x == 1) { /* ... */ }
```
```
assert(x != 1);
//... code that doesn't have any effect on x
```
The "undefined behavior" is that it allows these two to be
equivalent programs. You can reason about why the program isn't
doing what you want, so it's not that it's an "undefined
program", just that two (or more) definitions of a program are
equivalent as far as the D spec is concerned.
You don't know which one you can get, but you do know that they
are equivalent (because of your assertion).
Actually, what's really weird is the fact that no one would be
complaining if asserts were always checked, even though the above
is exactly what you could get by the optimizer. The real strange
thing is that you'd want the removal of checked asserts to change
the way your program can be optimized.
