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!

"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.
I think this should be allowed, but undefined, just like casting away const 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.
Agree.

> - Aliasing.
Not sure what you mean here...

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

Yes.

> I still believe!

:)

-Steve