const(FAQ)

[Davidson Corry]

Walter Bright wrote:
> The same questions about const come up repeatedly, so I decided that it 
> was past time to put up a FAQ dedicated to const. The initial version is 
> far from complete, but it's a start.
> 
> http://www.digitalmars.com/d/2.0/const-faq.html

Thank you! Very informative.

  ------------

I would find very helpful some further discussion of your thoughts on 
why const and invariant are crucial to multiprogramming. I sense that 
you are correct, but the details are yet murky to me.

I mentioned, over in the "const debacle' thread, that const on a 
parameter could be considered as part of the method's contract. And 
guslay, in this thread, noted the same thing:
 > Logical const is still const, as far has there is no visible (public)
 > side effect on the object. The implementation is still bound to that
 > contract. The result of .size() may still be cached.

That is, in some sense
	foo(const(X) x)
carries with it the (implied or express) postcondition
	out {
		x == old.x;
	}
which reads as "x looks just like it did when we got it".

On further thought, I realize that this is not strictly true. That is, 
it is true ONLY in the degenerate case of single-threaded execution: 
contracts (in Eiffel and D) allow the method to violate the class 
invariant "in the interim" -- that is, while executing private code, 
including private calls to subfunctions -- so long as the invariant is 
re-established at the time of the method return. Likewise, the 
postcondition doesn't have to be established until the method returns.

In single-threaded code, this much more limited guarantee is equivalent 
to "I'm not changing x anywhere in the middle", because there IS no one 
else using x while I've got control of it. But with multiprogramming, 
that's no longer true. The contract metaphor is no longer accurate.

The problems -- one for language designers, a different one for language 
users -- is that the "degenerate" case of single-threading IS 98% OF THE 
CODING WE DO, without even thinking about it. Pretty much all 
programming languages I know of have, built into their syntax**, the 
assumption that nothing else is happening but what they are doing:
	void foo() {
		some_statement;
				<--- what is happening here?
		some_other_statement;
	}
some_other_statement depends on the assumption that whatever 
some_statement did, nothing that it did has changed by the time 
some_other_statement gets control.

And I don't see how it could be otherwise. For that matter, HUMAN 
languages all make the same assumption. When I ask, "How about them 
'Blazers, guy?" I do not consider the price of first-quality saffron in 
Parma, even though that was going on, too. And if I put my lunch sack in 
the fridge at work and mark it 'const' (as in, "Please don't take my 
lunch"), that does not guarantee that Ralphie The Sandwich Pilferer 
isn't going to violate that "contract".

In human affairs, these things are handled by (at least) one of two 
methods: convention (social contract), or active intervention by someone 
named "manager" or "coordinator" (or in Ralphie's case, "hit man"...). 
These are analogous to "language feature" and "runtime code including 
library support", I believe.

In human affairs, the agents on the ground, the line workers, are the 
ones "who do the real work"... but without inserting the third-party 
manager AND GIVING UP SOME AUTONOMY to her (or to the "virtual" manager 
of convention), NOTHING OF SIGNIFICANT SCALE GETS DONE. I suspect that 
the analogy extends to coding. And I do not think that we have yet 
invented a workable (much less an elegant) syntax for relinquishing 
autonomy in programming.

** Some programming languages have added syntax features like 'lock', 
'synchronized' and 'separate' to support multiprogramming. I think it's 
clear they don't go far enough, yet. Likewise, I sense that 'const' and 
'invariant' will be fundamental here -- not sufficient, but necessary.
I'm looking forward to seeing it all evolve. Maybe even contributing a 
chromosome or two...

-- Dai

p.s. I note that the "social contract" bit applies to programming as 
well. D syntax can only protect you against other programs WRITTEN IN D, 
not against rm -rf *. And I'm not aware of any syntax constructs that 
can prevent my wife from hitting the power button before clicking 
"save"... and then blaming me for her work getting lost. <grin>