🚀 go-pugleaf

mbk@jt3ws1.etd.ornl.gov (Kennel) writes:

>Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
>> 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.
>
>Why do you always want to do that?  That's putting restrictions on what
>the caller can do with a thing.

Sure, you don't *always* want to do it, but often it is useful.
Being able to add restrictions is in general a useful thing.

>The most common use of "const" you want to ensure that the routine didn't
>do anything nasty behind your back.  
[...]
>Yes there are other uses for const, but I think those are better
>handled by regular types. 

I don't think so.  This has several problems.

One potential problem is that it requires multiple inheritence.
If a foo is-a bar, then a const-foo is-a const-bar.

		 const-bar
		  /	\
	    const-foo   bar
		  \	/
		    foo

Note that you want to use implementation inheritence to
implement this, not just interface inheritence.  So if your language
does not support multiple implementation inheritence, then you will
have serious trouble.

A more general problem is that it breaks encapsulation: the user of
`foo' who decides that they need a `const-foo' is in trouble if the
designer of `foo' didn't foresee that need.

A final drawback is that this technique generally requires lots
of boring, repetitive coding.

>> >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.
>
>The example that started this thread was a demonstration of when such
>a notion had undesirable consequences:  forcing a needless massive
>"reconsting" of a program or preventing "const" from being used in a
>natural way. 

I didn't see that example; perhaps you could repost it or a similar
example?

>> 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.
>
>But we already have types:  make an interface "NON_MODIFIABLE_FOOBAR"
>(or use Eiffel's qualified export capability) that says exactly what is
>and what isn't modifable.   I don't know about C++ but in Eiffel or Sather
>it's perfectly OK to hide modification routines of attributes from some 
>clients via interfaces. 

Yes, but doing this manually has all the problems I described above.

>And you have the full power of normal types in an integrated whole 
>instead of the special "const/non-const" cross "user_defined_types".

I agree that making the relationship between const and non-const too
special is undesireable.  It should be as close as possible to the
relationship between base class and derived class.  But I do think
that "const" is sufficiently useful to warrant special syntactic support.

>> 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.
>
>Yes, you're right about that.  But C doesn't even try, right?

No; but in C/C++, the type system carries around enough information
to ensure that aliasing analysis is not needed in order to prove
const-correctness, so the compiler doesn't need to try.
(That is, it doesn't need to try for the purposes of checking `const';
alias analysis may still be useful for optimization, of course.)

>I think aliased const modifications would have to be moved to a "warning"
>as not all could be detectable. 

What exactly do you mean by that?  Would the compiler warn about every
assignment that might possibly modify an aliased const?  If so, you
would get far too many spurious warnings; that would not be practical.

Or would the compiler only warn if it was sure an assignment was going
to modify an aliased const?  In that case, the compiler wouldn't be
able to provide useful guarantees at compile time.  The constness
annotations would be not be much of an improvment over ordinary
runtime-checked post-conditions.

>> I don't understand.  In C++, "constifying" one routine will not require
>> any changes to its callers either, will it?
>
>In the original example it did: you would have had to declare or
>make something a "const" type if I remember right.

Again, I missed the example, so if you could repost it, I'd be most obliged.

But I don't think there are any problems that couldn't be solved if the
caller was written correctly; the could be ensured by making `const'
the default and requiring an explicit `var' for variables, or by
getting compilers to warn about places where `const' ought to be
added.

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