forcing weak purity

[deadalnix]

Le 23/05/2012 14:35, Steven Schveighoffer a écrit :
> On Wed, 23 May 2012 08:21:42 -0400, deadalnix <deadalnix at gmail.com> wrote:
>
>> Le 23/05/2012 05:22, Steven Schveighoffer a écrit :
>>> I have come across a dilemma.
>>>
>>> Alex Rønne Petersen has a pull request changing some things in the GC to
>>> pure. I think gc_collect() should be weak-pure, because it could
>>> technically run on any memory allocation (which is already allowed in
>>> pure functions), and it runs in a context that doesn't really affect
>>> execution of the pure function.
>>>
>>> So I think it should be able to be run inside a strong pure function.
>>> But because it has no parameters and no return, marking it as pure makes
>>> it strong pure, and an optimizing compiler can effectively remove the
>>> call completely!
>>>
>>> So how do we force something to be weak-pure? What I want is:
>>>
>>> 1. it can be called from a pure function
>>> 2. it will not be optimized out in any way.
>>>
>>> This solution looks crappy to me:
>>>
>>> void gc_collect(void *unused = null);
>>>
>>> any other ideas?
>>>
>>> -Steve
>>
>> Why a pure function can call a collection cycle ???? This is an impure
>> operation by essence.
>
> Yes. Memory allocation and deallocation from a global heap is by
> definition an impure operation (it affects global state). However, we
> must make exceptions because without being able to allocate memory, pure
> functions become quite trivial and useless.
>
> In functional languages, if such exceptions were not granted, a program
> would not be able to do much of anything.
>

Yes, you are missing the point.

collect is not something you should be able to call in a pure function. 
It can be triggered by allocating, but at this point you already are in 
an impure context called from a pure context.

At the end, you need an unsafe way to call impure code in pure functions.

>> I think what is need here is to break the type system to allow call of
>> impure function into a pure one.
>
> We already are breaking the type system by marking an impure function (a
> function whose implementation is not marked pure) pure. This only works
> for extern(C) fucntions, which are not mangled with the pure attribute.
>
> But we need to be more specific about how the compiler should treat
> these functions. They need to undergo no optimization based on purity.
> They simply need to be able to be called from a pure function.
>
> -Steve