🚀 go-pugleaf

mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Matthew B. Kennel) writes:

>Arch Robison (robison@kai.com) wrote:
>
>: The keyword 'const' looks innocent at first, but introduces many
>: subtle complexities.  
[...]
>I think the problem with "const" as commonly known in C and C++ is
>that their model has a subtle, but fundamental intellectual error. 

I disagree.  If you don't like `const' in C/C++, blame the subtle
complexities, blame the old code you have to interface with, blame the
language for not including `template on const', or blame the problems
on `const' not being the default.  But don't put it down to
intellectual error, because the C/C++ model of `const' is perfectly
consistent.  It may not be the only model around, and it may
conceivably not even be the best one, but I wouldn't call it erroneous.

Personally I find `const' an extremely useful feature in both C and C++
and I am glad that they have it.  I think that if I used Java or
Eiffel, I would miss it.

>Using Eiffelish terminology, "const" as typically done now is like
>a *precondition*, but the actual idea that it is supposed to uphold
>is really a *postcondition*.

No, the idea that "const" in C/C++ is supposed to uphold is a type constraint.
A type consists of a set of values, and a set of operations on those
values (e.g. initialize, inspect, modify, ...).  A const type has the
same set of values, but a subset of the operations - only the ones that
don't modify the object (e.g.  initialize, inspect, ...).

>The notion that there are "types" which can be "const"ed means that this
>ends up---in some rough approximation---being a precondition to some
>routines:  a restriction on what sorts of things can be passed to the
>routine.
>
>However, that isn't really what we really want to express.  What you
>really want to do is restrict the operation of the ROUTINE! 
>
>The idea is that the ROUTINE which is called must guarantee that the
>reference which is passed "const" will not have modified data accessable via
>that pointer. 

Types allow you to do that.  Given an ADT, a routine can only apply
the operations specified by that ADT.

But types also allow you to do more.  Using postconditions only allows
you to ensure the constness of references passed to a routine.  Using
types also allows you to ensure the constness of references returned
from a routine.

>The fundamental difference between pre- and post-conditions is that
>preconditions put restrictions the caller, whereas postconditions
>put restrictions on the callee.

Right.  And types can put restrictions on both.  Which is exactly what
you want.

Anyway, postconditions aren't sufficient, because if you want to pass a
reference to an object which is shared with another thread or which is
stored in ROM) you also need to be able to prevent intermediate
modifications.  Types will allow you to do that; postconditions won't.

>IMHO what you want for "constness" is a *post*condition which verifies:
>
>	"is_provably_const(argument)" for all arguments which should
>	be 'const'. 
>
>{of course you should also permit is_provably_const(self)
> is_provably_const(this) is_provably_const(Current) for distinguished
> dispatch OO languages like ST, Eiffel, Sather, Java and C++}
>
>Then, the compiler would statically verify that "argument" was not changed,
>and fields accessible through "argument" or any variable aliased to the same
>object as that of "argument" were not changed, *and* that "argument"
>was only passed to other subroutines in positions which ALSO asserted
>"is_provably_const()" for the reference.  
>
>If the compiler is not able to do so, you will get a precise 
>compile-time error.

How is the compiler going to know which variables are aliased to which
other ones?

Are you supposing that the compiler should be required to do global
aliasing analysis?  If so, what level of precision of analysis would
you require?

That seems to me to be a very big problem for your approach.
You are presuming that the compiler has perfect aliasing information
at compile time.  But this is not the case in any of the languages
under discussion.

>Think about this model.  Now, if you "constify" one routine, you
>do NOT have this enormous chain of "reconsting" propagating throughout
>the program as you do in C++.  
>
>Instead, only the further routines which are *called* by the modified
>routines will have to be checked.  This is of course unavoidable as you must
>in fact guarantee that constant things are really constant.   

I don't understand.  In C++, "constifying" one routine will not require
any changes to its callers either, will it?

>Why has "const" been typically thought of as an implicit precondition?

"const" has *not* typically been thought of as a precondition.  It has
been thought of as a type constraint, which is a somewhat different
thing.  A type constraint on inputs is a precondition.  But a type
constraint on values returned from a routine is a postcondition.

>SUMMARY:
>
>	Yes, the notion of "is not changed" a.k.a. "constancy" is
>	a good one, but do NOT implement it as in C++ 'const'.
>
>	"constancy" is a *postcondition* on a routine, not a precondition.
>
>	Do not naively stuff it into types or argument signatures, which are 
>	preconditions.
>
>	Implement it as statically checkable postconditions instead.

If these postconditions are statically checkable, then how do they
differ from type constraints?

How is treating constancy as a postcondition any different to treating
it as a type constraint?  What problem does it solve?

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3