Poll: a nonstate keyword

[Fawzi Mohamed]

On 2008-05-31 07:40:56 +0200, "Janice Caron" <caron800 at googlemail.com> said:

> On 30/05/2008, Fawzi Mohamed <fmohamed at mac.com> wrote:
[...]
>> 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).
> 
> I don't think I've completely understood what you're trying to get at.
> Saying "basically haskell unsafePerformIO" tells me nothing, because I
> don't speak Haskell and have no idea what that means.

Sorry , basically I want a hack to convince the compiler that even if a 
function looks not pure it actually is.
Maybe a cast, like this (or with an uglier name)
pure int function(T) x=cast(pure int function(T))&y;
basically it says, to the compiler "yes I was careful and you can treat 
this function as pure, just do it, an if there are bug they are my 
fault because I am doing something potentially unsafe".

If there is something like this then no_state becomes useful, otherwise 
t is much less useful.

> 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.
In haskell this hole is called unsafePerformIO, and I think that it is 
a good name because when you use it it makes it very clear that you are 
on your own on slippery soil... :)

Fawzi