Poll: a nonstate keyword

[Fawzi Mohamed]

On 2008-05-30 08:08:35 +0200, "Janice Caron" <caron800 at googlemail.com> said:

> On 29/05/2008, Fawzi Mohamed <fmohamed at mac.com> wrote:
>> but can break invariant
> 
> That part is not correct. A couple of months back, I submitted a paper
> to Walter and the gang, based on these ideas, in which I showed that
> the transitive closure of const/invariant remained fully intact under
> this model. Andrei confirmed that I was correct, and subsequently
> tried to help explain it to Walter.

Indeed there are two ways to introduce mutable space.
The first one that gives access to the mutable space also to pure 
functions (but potentially breaks everything).
The catch is that by default updates to this mutable state might get 
lost due to compiler optimizations (as the compiler is free to float 
pure functions on them out of a loop, or to copy invariant objects), 
and this should be considered ok (which means that the result of the 
program cannot depend on this mutable state).
This can be used to implement efficiently memoization and lazy caching 
also for pure functions (which I want).

The other possibility (that Steven and you propose, if I understood 
correctly) is to disallow pure functions to access mutable state. This 
diminished the usefulness of pure functions or mutable state depending 
from how you look at the problem.
Indeed this solution does not break  invariance.

If implicit automatic copies (without calling a copy method) of object 
or part of it are allowed then the picture becomes more complex, but 
such a thing has a questionable value.

>> and introduce subtle bugs.
> 
> That part is probably true, but it depends on whether or not people
> "get it", which I think is what Steven was asking. Consider the
> following (legal) code
> 
>     struct A
>     {
>         static int n;
>     }
> 
>     invariant A a;
>     a.n = 42;
> 
> I don't think anyone would argue that "static breaks invariant", but
> could you say that code like the above "introduces subtle bugs"?
> Maybe. Maybe not. It depends on understanding.
> 
> "nonstate" has been known by other names in previous discussions,
> including "unpaintable". (There was quite a long thread with that
> one). The general feeling over at Phobos is that the number of
> use-cases is small enough that a handful of library solutions could
> eliminate the need for the keyword. The problem, as I see it, is that
> those library solutions have been talked about, but not yet
> implemented. Consequently, there is still a perceived need for
> "nonstate" - a perceived need which would go away as soon as those
> alternative solutions were made available.

I agree that a good library implementation is what one should strive to-
The question is how to implement them.
Without keyword one could achieve this using fully unsafe casts, I 
think, but is something like that allowed in a pure function?
If the answer is no, then to be able to implement them in plain D in a 
library the keyword would still be needed, or a way to declare an 
unsafe function pure (basically haskell unsafePerformIO).