checkedint call removal

Chris Cain via Digitalmars-d digitalmars-d at puremagic.com
Sat Aug 2 01:58:47 PDT 2014


On Saturday, 2 August 2014 at 07:36:34 UTC, Tofu Ninja wrote:
> On Saturday, 2 August 2014 at 06:35:33 UTC, Chris Cain wrote:
>
>> 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
>
> Yes.... I disagreed with you... so yes I am saying something
> different. What else is "disagreement" supposed to mean?
>
>> 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.
>
> I understood what you said, I just disagreed with it. Are you
> saying I can't disagree???

It depends on what you mean. You can disagree, but you can't 
disagree with the fact that what I said and what you seem to 
suggest I am saying are two different things.

So, in particular,

> So a statement of fact is
> simply the communication that the fact exists.

Is something that seems to be suggesting a meaning in my words 
that doesn't exist.

Really specifically, I have a problem with "a statement of fact 
is simply the communication that the fact exists." -> It's a form 
of communication, but since a fact is defined as "something that 
is actually the case/exists" and a statement of fact actually 
isn't communicating that, then it makes a very real difference in 
the potential interpretation of the words. In particular, your 
definition of what I'm saying seems to imply that a "statement of 
fact" suggests that a proof of that fact must exist before an 
assertion is really an assertion, whereas a real statement of 
fact doesn't necessarily have a proof of true or false just that 
it *could be verified.* Thus an assertion without a proof is 
still an assertion and communicating an idea that doesn't 
necessarily have to be proven to finalize the communication. It's 
just that, in particular, the idea communicated is a statement of 
fact iff it were verifiable. Effectively that definition is just 
removing extraneous things like beliefs, "god exists", "there 
exists parallel universes that cease to exist the instant you 
attempt to observe them", etc. Things that you couldn't verify or 
falsify.

Basically, because we've had enough problems with what is being 
actually being said, trying to take some liberties with what is 
being said and trying to subtly change it is completely out of 
the question. Until we start coming to an exact understanding of 
what each other means, it's probably best if we don't disagree 
with what the other person has defined as what they mean and 
instead try to figure out what is being said.

If you want to introduce your own definitions and such, make it 
clear (that is, don't start your paragraph with "I think what you 
are calling a..." because it's prompting me to carefully consider 
what you're saying as potentially redefining what I'm saying). It 
just seemed to me that you were taking my words and trying to 
suggest that I don't understand my own words or something. If 
that wasn't what you were trying to do, I'm sorry.

>> 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.
>
> None of these words or phrases are well defined.... if assert 
> was
> well defined we would not be talking now....

That's not necessarily true. Disagreements exist on well-defined 
definitions all the time.

> I understand your argument, I just don't think it is correct.
> Particularly I don't agree that your interpretation of assert
> more closely matches the real meaning of assert. Let me 
> reiterate
> why...
>
> When something is asserted, there is the asserter(the person
> making the assertion) and the asserti(s)(the person/people that
> are hearing the assertion). Given that any thing that is 
> asserted
> can either be true or false, the asserti has no choice but to
> conclude that what is being asserted may or may not be true.
>
> In the context of the programmer(asserter) and the
> compiler(asserti). The programer is making an assertion that the
> compiler must conclude to be either true or false. Because it
> does not know if it is true or not, the only time it is
> acceptable for the compiler to optimize as if it is true is to
> actually check if it is true.

True, iff the asserter and assertee are human and doubt the 
assertion. Assertions are typically taken until someone calls 
into question the assertion. The compiler doesn't call into 
question anything you do unless it has a proof that what you're 
doing is wrong.

In particular, I take much of what you say to be truth, even if I 
haven't explicitly asked you to verify it before we accept it as 
truth. Furthermore, much of what you say isn't backed up with 
proof at all (and yet I still accept it without proof). In fact, 
the vast majority of conversations will do so (otherwise 
absolutely nothing productive could be accomplished). That said, 
if I have a reason to believe you are making an incorrect 
assertion, I will either ask you to verify it or prove you wrong 
about it. This makes conversations much faster since we often 
assume things to be true if asserted true by the other party, 
often skipping checks and verifications that would otherwise 
potentially be necessary.

Obviously it's starting to sound a lot more like what a compiler 
does when optimizing a program. When you assert something to the 
compiler, it accepts it as true unless it has a really good 
reason to believe it is logically inconsistent (that also 
suggests that the compiler even tried to make sure it's logically 
consistent, which I think would be a nice feature to have).

> The point is that without the check, the assertion is neither
> proven or disproven. If the compiler receives bad
> input(incorrectly defined input is not bad input), then it knows
> it is bad, but the compiler has no way of knowing if an 
> assertion
> is good or bad.

I get your point, but I see asserts in the same class as most 
(all?) other mechanisms. If it does not have a proof against what 
you say, then it will not step in. You don't have to write proven 
programs in general.

Since it doesn't have to prove your assertion (and it can't in 
general, so that's a good thing), then it must accept your 
assertion as good just like it accepts all of your other code as 
logically good unless it has a reason to believe that it's not.

> If the compiler receives two asserts that can not both be true,
> then there is no way it can know what to do, there is no
> resolution. But if the compiler is not smart enough to recognize
> that they are contradictory then is just compiled an 
> uncompilable
> program....

I've already covered that I think things that are provably false 
might be helpful if the compiler actually pointed out the error. 
That said, it's not a trivial problem to solve, so it's not 
surprising that it doesn't solve it.

> I can understand why you think that, I just don't agree. I don't
> agree that an assertion in the english language means that
> something will be true, I interpret it as a claim that something
> may or may not be true.

Of course. But what point is there in telling a compiler that? 
Obviously there's no point unless you're communicating some idea 
to the compiler and communicating to the compiler that "here's 
something that may or may not be true, so don't do anything about 
it" is completely odd, strange, and special (in the sense that 
there doesn't exist any other construct that I can think of that 
does that... even ASM noops, which literally mean "do nothing", 
have a purposeful effect on a program).

I expect a compiler to help me out, but ultimately I expect it to 
trust my logic even if it can't verify it. Specifically, I don't 
mind it stepping in with counter proofs to my suggestion that I 
have a good program. But if it doesn't know whether my program is 
good or not, I expect it to assume it is good. I've already shown 
that your expectations for `if` statements and function calls are 
almost certainly the same as my expectations for all language 
features.

> That is not an undefined program.... the code you just presented
> was completely defined. An an example of an undefined program
> with respect to assert is as follows.
>
> assert(x==1);
> assert(y==2);
>
>
> Lets say the compiler was not smart enough to see that these
> could not both be true. There is no way the compiler can produce
> and thing that is correct because they both cannot be true. 
> There
> will always be sets of conditions that the compiler can not 
> prove
> to be contradictory(because of the halting problem) but that 
> are.
> That is an undefined program...
>
>> The "undefined behavior" is that it allows these two to be 
>> equivalent programs.
>
> That is not the undefined behavior

Fine, I see what you mean. But I don't find it persuasive because 
I just see it as a bad program no different than one constructed 
from any other logic error. It'd be nice to have better 
constructs to help prove correctness, but we can't do it in 
general.

But in the context of what we actually can do, asserts make sense 
to behave as described in this thread.

> That is actually the point, no one would be complaining because
> there would be nothing wrong. There would be no chance of
> undefined behavior. If the check is always there then the 
> program
> will always know that after the assert the condition is true and
> would be free to do any optimizations it wants. The undefined
> behavior occurs when you optimized as if they are true but do 
> not
> check.

Actually, there would be something wrong. Two *very* different 
programs would be compiled between an optimized build with 
checked assertions and a program without checked assertions.

The difference of the programs with asserts as described in this 
thread would be precisely the asserts themselves, which is 
absolutely what you'd expect. No one would expect that removing 
asserts could completely change *everything* about the code, 
which is what is concluded by the behavior you describe.

Of course, you could suggest that "asserts shouldn't affect 
optimization" -> but the problem there is that it matches no 
definition of the English language version of assert because it 
means "check to see if this is true" which is very, VERY far away 
from the definition of "statement of fact forcefully". Hence why 
I'm very eager to cast off that definition because it has a 
meaning that is no where near the English definition.


More information about the Digitalmars-d mailing list