secure const and

[Fawzi Mohamed]

I have tried to move part of this argument to the wiki.
I have created a page at

  http://www.prowiki.org/wiki4d/wiki.cgi?TransitiveConst

feel free to add to it.

My main point is that I like Stevens proposal, but I think it should be 
seen as a hole to implement *secure* relaxations of the const concept, 
and so it should be clearly marked as a hole not to be used unless 
absolutely needed (and that will be in low level libraries).

The secure abstractions are secure enough to be allowed also in pure 
functions and invariant data structures, without breaking anything 
(only extension 2 adds a constraint more to the optimizations allowed, 
namely that copied data should be synchronized, but as I describe it 
still a very well behaved extension).

So I want that even pure functions have access to these mutable parts 
of the object, and if something bad happens the fault is obviously the 
fault of the programmer that used the hole in const in a bad way.
This will make pure function more flexible, faster, and more likely to 
be written and used, something from which everybody should profit.

I think that I identified all reasonable use of mutable state in a 
const object, if you think I missed something, please add it.

As I say in the wiki also haskell (a language that considers 
provability quite important) has an uncontrolled hole (unsafePerformIO) 
that *is* used in special cases and it is the responsibility of the 
coder to make sure that it is used correctly. Also the monads laws are 
not verified by the compiler, it is just assumed that the implementor 
wrote them correctly.

Fawzi