View mode: basic / threaded / horizontal-split · Log in · Help
April 04, 2008
Re: Fully transitive const is not necessary
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!
April 04, 2008
Re: Fully transitive const is not necessary
"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
Top | Discussion index | About this forum | D home