www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - secure const and

reply Fawzi Mohamed <fmohamed mac.com> writes:
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
Apr 06 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Fawzi Mohamed wrote:

 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

Any way to add a table of contents? I'd also hope that the page would be restructured to give people the opportunity to talk about the pros of verious methods without arguing... Maybe something like a background section. Of course, then there can be a few proposal sections where arguing can be rampant :) There should probably be a separate section for bicycle shed discussions.
Apr 06 2008
parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-04-06 15:31:02 +0200, Jason House <jason.james.house gmail.com> said:

 Fawzi Mohamed wrote:
 
 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.
 [....]


done
 I'd also hope that the page would be restructured to give people the
 opportunity to talk about the pros of verious methods without arguing...
 Maybe something like a background section.

Restructure it as you see fit to improve the ability to make the wiki evolve.
 Of course, then there can be a few proposal sections where arguing can be
 rampant :)  There should probably be a separate section for bicycle shed
 discussions.

Comments and Implementation Proposal sections should be more arguing free.
Apr 06 2008