forcing weak purity

[Alex Rønne Petersen]

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!
>> }
>>
>
> 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.

>
> So basically the allocation mecanism have to break the type system to
> act like it is pure, even if it isn't.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org