forcing weak purity

[deadalnix]

Le 23/05/2012 15:47, Alex Rønne Petersen a écrit :
> On 23-05-2012 15:46, deadalnix wrote:
>> Le 23/05/2012 14:32, Alex Rønne Petersen a écrit :
>>> On 23-05-2012 14:21, deadalnix 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.
>>>>
>>>> I think what is need here is to break the type system to allow call of
>>>> impure function into a pure one.
>>>
>>> I think you're missing an amusing point:
>>>
>>> class C { this() pure {} }
>>>
>>> C foo() pure
>>> {
>>> return new C(); // can trigger a collection!
>>> }
>>>

Rethinking about this, it show something interesting. To make sense, 
allocation in pure function should either be scoped or immutable.

Otherwise we can't ensure any « strong purity » on a function that 
return anything that can reference something else.

>>
>> Ok, but no direct call to GC collect will be done, so the function don't
>> need to be pure, it need to be somehow hacked into the allocation
>> mecanism, probably using compiler magic.
>
> Sure there'll be a direct call to that. It's effectively what the GC
> does when collecting.
>

At this point, you are in the allocation mecanism in druntime. You are 
not in pure code anymore.

If it is the case, then the type system is broken at the wrong place.