View mode: basic / threaded / horizontal-split · Log in · Help
May 23, 2012
forcing weak purity
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
May 23, 2012
Re: forcing weak purity
On 23-05-2012 05:22, Steven Schveighoffer wrote:
> 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

I'm in favor of what you suggested on GitHub: A @weak attribute to 
enforce weak purity for functions marked pure.

BTW, any compiler with alias analysis and LTO might even decide to 
remove the call even with the unused parameter, since it, well, isn't 
used. I think we need a language-level solution here.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 23, 2012
Re: forcing weak purity
We should make 'pure' mean strongly pure.

For weakly pure, we could introduce the 'doped' keyword :-D
May 23, 2012
Re: forcing weak purity
On 23/05/12 07:05, Mehrdad wrote:
> We should make 'pure' mean strongly pure.
>
> For weakly pure, we could introduce the 'doped' keyword :-D

No, the keyword should be more like @noglobal

I wish people would stop using this "weak purity" / "strong purity" 
terminology, it's very unhelpful. (And it's my fault. I've created a 
monster!)

There is absolutely no need for a keyword to mark (strong) purity, and 
"weak purity" isn't actually pure.

The real question being asked is, do we need something for logical 
purity? Note that we need the same thing for caching.

Or are the cases like this rare enough that we can just fake it with a cast?
May 23, 2012
Re: forcing weak purity
On Wed, 23 May 2012 06:00:11 -0400, Don Clugston <dac@nospam.com> wrote:

> On 23/05/12 07:05, Mehrdad wrote:
>> We should make 'pure' mean strongly pure.
>>
>> For weakly pure, we could introduce the 'doped' keyword :-D
>
> No, the keyword should be more like @noglobal

Well, it's actually @noglobalorshared

> I wish people would stop using this "weak purity" / "strong purity"  
> terminology, it's very unhelpful. (And it's my fault. I've created a  
> monster!)

I think the feature itself is essential and useful.  I just think it's a  
victim of historical naming.

>
> There is absolutely no need for a keyword to mark (strong) purity, and  
> "weak purity" isn't actually pure.

Now that we have the proverbial foot in the door, and we see that weak  
pure... er.. noglobal functions are very useful, it might be worth  
investigating whether it makes sense to rename the keywords.

I agree that 'pure' is somewhat misleading on noglobal functions, simply  
because of the history of the pure keyword in other languages.  But I  
really like how you don't have to care whether a function is actually pure  
or just noglobal, the compiler has a better perspective on what is fully  
pure and what is noglobal.

So are you suggesting that we replace pure wholesale with another keyword  
that better describes what D purity is?  Or are you suggesting that we  
have to specifically mark fully-pure functions as pure to get the benefits?

> The real question being asked is, do we need something for logical  
> purity? Note that we need the same thing for caching.

Yes.  Memory allocation and deallocation is *not pure*, since it affects  
global state.  But it should never participate in optimization.

> Or are the cases like this rare enough that we can just fake it with a  
> cast?

As long as we can have a way to say "this can be called from pure/noglobal  
functions, but should *not* participate in pure optimizations", I think  
it's a valid solution.

-Steve
May 23, 2012
Re: forcing weak purity
On Tue, 22 May 2012 23:31:59 -0400, Alex Rønne Petersen <alex@lycus.org>  
wrote:

> On 23-05-2012 05:22, Steven Schveighoffer wrote:
>
>> This solution looks crappy to me:
>>
>> void gc_collect(void *unused = null);
>
> BTW, any compiler with alias analysis and LTO might even decide to  
> remove the call even with the unused parameter, since it, well, isn't  
> used. I think we need a language-level solution here.

The LTO would have to be able to make decisions at link time based on  
purity, because the call *does* do things, it just doesn't use the  
parameter.  I have no idea, maybe you are right, it would be a hard  
problem to fix if this happened.

-Steve
May 23, 2012
Re: forcing weak purity
On 05/23/12 05:22, Steven Schveighoffer wrote:
> 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!

Arguably a pure function not returning a value doesn't make sense... D's definition
of "pure" makes things a bit more complicated, and the fact that it is so vaguely
defined doesn't help. Eg what does "a pure function can terminate the program" mean?
A literal interpretation forbids eliminating any calls, or even moving them in a way
that could affect control flow (by terminating early/late)...

Anyway, result-less "pure" functions obviously can have side effects, so removing
calls to them shouldn't be allowed.


On 05/23/12 05:31, Alex Rønne Petersen wrote:
> I'm in favor of what you suggested on GitHub: A @weak attribute to enforce weak purity for functions marked pure.

No. "@weak" should be for defining weak symbols, reusing it for anything else would
just cause confusion,

artur
May 23, 2012
Re: forcing weak purity
On 05/23/12 13:45, Steven Schveighoffer wrote:
> On Tue, 22 May 2012 23:31:59 -0400, Alex Rønne Petersen <alex@lycus.org> wrote:
> 
>> On 23-05-2012 05:22, Steven Schveighoffer wrote:
>>
>>> This solution looks crappy to me:
>>>
>>> void gc_collect(void *unused = null);
>>
>> BTW, any compiler with alias analysis and LTO might even decide to remove the call even with the unused parameter, since it, well, isn't used. I think we need a language-level solution here.
> 
> The LTO would have to be able to make decisions at link time based on purity, because the call *does* do things, it just doesn't use the parameter.  I have no idea, maybe you are right, it would be a hard problem to fix if this happened.
>

A compiler can, once it notices the unused argument(s), (more or less) easily rewrite
(clone) the function and modify the callers to use the new version. And when the LTO
pass (re)compiles the program (from the intermediate representation in the object files)
it could already see the cloned version, and optimize based on that. So it is possible.

artur
May 23, 2012
Re: forcing weak purity
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.
May 23, 2012
Re: forcing weak purity
On 23-05-2012 13:48, Artur Skawina wrote:
> On 05/23/12 05:22, Steven Schveighoffer wrote:
>> 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!
>
> Arguably a pure function not returning a value doesn't make sense... D's definition
> of "pure" makes things a bit more complicated, and the fact that it is so vaguely
> defined doesn't help. Eg what does "a pure function can terminate the program" mean?
> A literal interpretation forbids eliminating any calls, or even moving them in a way
> that could affect control flow (by terminating early/late)...
>
> Anyway, result-less "pure" functions obviously can have side effects, so removing
> calls to them shouldn't be allowed.
>
>
> On 05/23/12 05:31, Alex Rønne Petersen wrote:
>> I'm in favor of what you suggested on GitHub: A @weak attribute to enforce weak purity for functions marked pure.
>
> No. "@weak" should be for defining weak symbols, reusing it for anything else would
> just cause confusion,
>
> artur

I had no idea what weak symbols were until I read your post. Just due to 
that fact, I am not convinced that weak symbols are interesting enough 
to occupy @weak.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home