🚀 go-pugleaf

Fergus Henderson (fjh@munta.cs.mu.OZ.AU) wrote:
> 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.

I agree it's consistent: it's the notion that this kind of consteness ought 
to be part of type which I think is an error in judgement.

I'm not talking about an "internal consistency or logical error". 

What is the motivation behind constancy?  To prevent human errors

> 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.

Which is what I don't think is desirable. 

> 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, ...).

And implicit conversions between const types and their 'regular' counter
parts. 

Of course, with the right interfaces you can already explicitly make types 
which present some full interfaces (permitting "writing") to some clients
and which present restricted interfaces (permitting only reading) to others.

These things are already in the normal Eiffel typesystem.

> 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.

Why do you always want to do that?  That's putting restrictions on what
the caller can do with a thing.

The most common use of "const" you want to ensure that the routine didn't
do anything nasty behind your back.  

Anthropomorphizing an object, "why
should *I* not be allowed to modify some object?  I might even have
created it for Ritchie's sake! I just want to make sure I can trust that
Other Routine to not screw me over.  I don't want to 'marry the mob' and
have it come back as a prissy 'const virgin'. "  

:-) 

Yes there are other uses for const, but I think those are better
handled by regular types. 

> >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. 

> 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. 

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

A postcondition notion of const would express something intrinsically
different from types, and would solve many of the interfacing problems
people have with existing "const". 

> 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?
I think aliased const modifications would have to be moved to a "warning"
as not all could be detectable. 

> 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.

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

Becuase they don't put any burden on the caller, which a type constraint
does:  the notion of "const vs non const" leaks out because of the
somewhat types. 

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

I can't find it now, but the original article in this thread showed
the problem. It was a suggestion to add C++ const to Java, this example
was part of the admitted problems you would get.  

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