Jump to page: 1 25  
Page
Thread overview
forcing weak purity
May 23, 2012
Artur Skawina
May 23, 2012
Mehrdad
May 23, 2012
Don Clugston
May 23, 2012
bearophile
May 23, 2012
Artur Skawina
May 23, 2012
deadalnix
May 23, 2012
deadalnix
May 23, 2012
deadalnix
May 23, 2012
deadalnix
May 23, 2012
deadalnix
May 23, 2012
deadalnix
May 23, 2012
Don Clugston
May 23, 2012
deadalnix
May 23, 2012
Don Clugston
May 23, 2012
deadalnix
May 23, 2012
deadalnix
May 24, 2012
Don Clugston
May 25, 2012
H. S. Teoh
May 23, 2012
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
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
We should make 'pure' mean strongly pure.

For weakly pure, we could introduce the 'doped' keyword :-D
May 23, 2012
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
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
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
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
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
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
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