Poll: a nonstate keyword

[Fawzi Mohamed]

On 2008-05-31 11:37:44 +0200, "Janice Caron" <caron800 at googlemail.com> said:

> On 31/05/2008, Fawzi Mohamed <fmohamed at mac.com> wrote:
>> Sorry , basically I want a hack to convince the compiler that even if a
>> function looks not pure it actually is.
> 
> The one example of this which I can recall, which has been
> demonstrated in this forum, is calling a "helper function" from within
> a pure function. Is that what you're talking about? If so, it's been
> mentioned before. Here's an example:
> 
>     void helper(char[] s) // not pure
>     {
>         s[0] = 'J';
>     }
> 
>     string foo(string s) pure
>     {
>         char[] tmp = s.dup;
>         helper(tmp);
>         return assumeUnique(tmp);
>     }
> 
> Currently, it seems that the above might not be legal code, since pure
> functions cannot call non-pure functions. However, what makes this
> case (and others like it) special is that, although helper itself is
> not pure, if it were inlined, it wouldn't stop foo from being pure.
> 
> This has been pointed out before, and I am /sure/ that Walter will
> come up with a solution which makes it possible (though not
> necessarily in the first attempt).
> 
> I have absolutely no idea, however, what this has to do with Steven's
> question. Is it relevant, or are we heading off-topic?

but yes with this we are heading off-topic, what I meant is
1) I want a loophole to be able to access this no state mutable state 
also in pure functions (even if I know that in general this should not 
be allowed as it potentially breaks everything)

2) if there is a way to convince the compiler that a non pure function 
should be treated as a pure function (and this is what I was after 
before) then the "safe" no_state can be used to achieve 1).

If the following works:
>> Maybe a cast, like this (or with an uglier name)
>> pure int function(T) x=cast(pure int function(T))&y;
> 
> The way I read it, the following will work, as is already legal syntax
> 
>     auto x = cast(function int(T) pure)&y;

then basically we have 2)
int potentiallyUnsafe(T x){ ...}

pure int ITellYouItIsSafe(T x){
  return (cast(function int(T) pure)&potentiallyUnsafe)(x);
}

(I am surprised at how harmlessly it looks)
and adding no_state is equivalent with the more powerful (and 
dangerous) version that I want.

>>> One of the advantages of pure functions, however, is that (like
>>> inlining) memoization can be done /by the compiler/, so you don't have
>>> to do it yourself. How good a job the compiler will do remains to be
>>> seen. My guess would be, poor at first, getting increasingly better
>>> over time.
>> 
>> Sorry that is not good enough for me I want functions lifted out of inner
>> loops, and a compiler that says to me either you use the slow pure function,
>> and I will lift it out of the loop, or the fast one, but it will stay in the
>> loop, is not good enough for me.
>> I want a hole to be able to trick the compiler into floating out the fast
>> function.
> 
> I still don't get it. Can you show me what you mean with an example?

This is like a generalization of the array indexing example

starting with a code like this:
  void g(int i, const Pippo x, Pippo y){
	auto t=pureF(x);
	y.doSomething(t,i);
  }

then this loop
  for (int i=0;i<100;i++)
    g(i,x,y);
should be transformed as follow:
inline g:
  for (int i=0;i<100;i++){
	auto t=pureF(x);
	y.doSomething(t,i);
}

move pureF(x) outside the loop:
  auto t=pureF(x);
  for (int i=0;i<100;i++){
	y.doSomething(t,i);
}

This last operation is valid *only* if pureF is pure.
Now imagine that the previous fragment is called several times, and 
that memoization in pureF can improve much its performance.
Then I either have to choose to use memoization (but then the function 
is not pure anymore for D, and it stays in the loop) or avoid 
memoization, and the function is pure but then pay the penalty later 
when the previous code snipped is calculated several times.
I want it all, I want it to be possible to have memoization a purity 
related optimizations.

It seems that with a safe no_state and a cast this is possible, so yes 
I very much want no_state.

Fawzi