• guslay <guslay gmail.com> Apr 04 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Apr 04 2008

guslay <guslay gmail.com> writes:

Just a quick reply, I still this it should be discussed elsewhere...

 If we say that the mutable part of invariant A is not accessible during pure
 functions, then (A = B = C) holds true.  In fact, I would argue that for
 logical const, the mutable part is not part of the invariant A instance, but
 is an 'associated' or 'tacked-on' piece that happens to be carried around
 with A.  It is used by A to help for various tools such as syncrhonization,
 memoization, etc, but it is not part of A's state.  Think of it as living in
 A's namespace, but not in the instance, and so it is inaccessible to pure
 functions.
 
 -Steve 


My idea was that you cannot prove A = B = C if pure functions can access
mutable members of an invariant object.

- Class A has a mutable _lock member
- f = isLocked() pure
- g = unlock() unpure


But now that I think of it, you are right, the same constraints also applies to
global state. So tho make purity works, you would need to applies the same
rules to mutable members as to global states:

Minimally,
- Forbid pure functions to call non-pure functions or to access mutable members
directly.
- Forbid pure functions to call non-pure functions or to access mutable global
state directly.

More drastically,
- Forbid invariant object with mutable members to take any part in pure
expressions.
- Forbid invariant object with accessing mutable global states to take any part
in pure expressions.


To only things I see that can break a pure method are:

- If A is abstract type, can the concrete type of the object subvert the purity
analysis.
- Casting inside the pure function.
- Invariant parameter not really invariant.
- Aliasing.

All those things are some sort of cheating, and those have nothing to do with
mutable members.


I still believe!

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"guslay" wrote
 Just a quick reply, I still this it should be discussed elsewhere...


I like this forum, as it allows people to make points where people who might 
be interested are usually listening.  Walter also at least reads the NG. 
Outlook Express automatically threads the NG for me, so if there is a thread 
I'm not interested in, I just ignore it (the web interface sucks, don't use 
it :) ).  Another form of discussion might not be heard by people who have 
good ideas, and I'd rather everything be open.  If people don't want to 
discuss this, just ignore the thread.

 More drastically,
 - Forbid invariant object with mutable members to take any part in pure 
 expressions.


I don't think this is possible without fully transitive const, as the 
compiler cannot be sure that a derived class or concrete implementation does 
not use mutable members.  This could be accomplished with extra tagging, 
i.e. transitive invariant / logical invariant.  That being said, I don't 
think this is necessary.

 To only things I see that can break a pure method are:

 - If A is abstract type, can the concrete type of the object subvert the 
 purity analysis.


Since a pure function can only call other pure functions, purity is fully 
transitive (and has to be in order to be statically verified), and therefore 
you cannot subvert the purity analysis in a derived type because you should 
only be able to implement/override a pure method signature with a pure 
method.

However, the cheats below can do this, so this is really a result of one of 
the cheats :)

 - Casting inside the pure function.


is.  There may be cases where casting can allow for a huge optimization, and 
still be a pure function, but there is no way to statically analyze it.

 - Invariant parameter not really invariant.



 - Aliasing.



 All those things are some sort of cheating, and those have nothing to do 
 with mutable members.


Yes.

 I still believe!


:)

-Steve