December 20, 2016 Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
https://github.com/dlang/dlang.org/pull/1528 -- Andrei |
December 21, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On 20.12.2016 23:49, Andrei Alexandrescu wrote:
> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Good, except:
"$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)"
I think this makes no sense. What is the idea behind this paragraph?
|
December 20, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 12/20/16 7:40 PM, Timon Gehr wrote:
> On 20.12.2016 23:49, Andrei Alexandrescu wrote:
>> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
>
> Good, except:
>
> "$(P `pure` functions returning `void` will be always called even if it
> is strongly `pure`. The implementation must assume the function does
> something outside the confines of the type system and is therefore not
> allowed to elide the call, even if it appears to have no possible effect.)"
>
> I think this makes no sense. What is the idea behind this paragraph?
A function that traces execution via a debug statement, for example. -- Andrei
|
December 20, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tue, Dec 20, 2016 at 07:58:38PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/20/16 7:40 PM, Timon Gehr wrote: > > On 20.12.2016 23:49, Andrei Alexandrescu wrote: > > > https://github.com/dlang/dlang.org/pull/1528 -- Andrei > > > > Good, except: > > > > "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)" > > > > I think this makes no sense. What is the idea behind this paragraph? > > A function that traces execution via a debug statement, for example. -- Andrei Isn't that impure by definition?! How can tracing execution even be remotely considered pure? I understand that debug statements are a kind of backdoor to facilitate debugging... but still. I'd expect we wouldn't bend the definition of pure just for the sake of debugging -- that just sounds backwards. If a function has side-effects outside of what's passed as arguments, I can't see any way of justifying it being marked as pure. T -- They pretend to pay us, and we pretend to work. -- Russian saying |
December 20, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tuesday, December 20, 2016 19:58:38 Andrei Alexandrescu via Digitalmars-d wrote:
> On 12/20/16 7:40 PM, Timon Gehr wrote:
> > On 20.12.2016 23:49, Andrei Alexandrescu wrote:
> >> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
> >
> > Good, except:
> >
> > "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of the type system and is therefore not allowed to elide the call, even if it appears to have no possible effect.)"
> >
> > I think this makes no sense. What is the idea behind this paragraph?
>
> A function that traces execution via a debug statement, for example. -- Andrei
Well, ultimately, strongly pure functions that return void are either doing something that works around the type system (e.g. using debug statements to do operations which aren't pure), or they arguably shouldn't even compile, because they can't possibly do anything that has any effect on the program beyond eating up CPU time. So, as far as I can tell, we should either make an exception for them (as the PR currently does) or make them illegal.
- Jonathan M Davis
|
December 21, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Wednesday, 21 December 2016 at 00:58:38 UTC, Andrei Alexandrescu wrote:
> On 12/20/16 7:40 PM, Timon Gehr wrote:
>> On 20.12.2016 23:49, Andrei Alexandrescu wrote:
>>> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
>>
>> Good, except:
>>
>> "$(P `pure` functions returning `void` will be always called even if it
>> is strongly `pure`. The implementation must assume the function does
>> something outside the confines of the type system and is therefore not
>> allowed to elide the call, even if it appears to have no possible effect.)"
>>
>> I think this makes no sense. What is the idea behind this paragraph?
>
> A function that traces execution via a debug statement, for example. -- Andrei
The compiler will have to be changed for this part. Currently it's a warning (or maybe it was an error, can't remember) to call a strongly pure function returning void without doing `cast(void)fun()`.
|
December 20, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On 12/20/16 8:10 PM, Meta wrote:
> The compiler will have to be changed for this part. Currently it's a
> warning (or maybe it was an error, can't remember) to call a strongly
> pure function returning void without doing `cast(void)fun()`.
Interesting. As soon as the spec change is merged, we get to file an issue :o). -- Andrei
|
December 20, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote:
> Isn't that impure by definition?! How can tracing execution even be
> remotely considered pure?
That's why the compiler is required compulsively to call it. -- Andrei
|
December 20, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote: > > Isn't that impure by definition?! How can tracing execution even be remotely considered pure? > > That's why the compiler is required compulsively to call it. -- Andrei I don't follow. The question was how can a function with side-effects (even given D's relaxed definition of pure, i.e., allowing mutation via arguments) can be considered pure. What has that got to do with the compiler being required to call it? I'd say a pure void function should be equivalent to no-op and elidable. If you want to call a function with side-effects from pure code for debugging purposes, call it via the debug statement, e.g.: void impureDebugger(...) { ... } // N.B.: NOT pure pure void noop() {} pure auto pureFunc(A...)(A args) { ... noop(); // may be elided ... debug impureDebugger(1,2,3); // won't be elided ... } I don't see any good reason why we should bend the definition of pure to allow pure void functions with side effects. T -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth |
December 20, 2016 Re: Improvement in pure functions specification | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 12/20/16 8:54 PM, H. S. Teoh via Digitalmars-d wrote:
> On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote:
>>> Isn't that impure by definition?! How can tracing execution even be
>>> remotely considered pure?
>>
>> That's why the compiler is required compulsively to call it. -- Andrei
>
> I don't follow.
>
> The question was how can a function with side-effects (even given D's
> relaxed definition of pure, i.e., allowing mutation via arguments) can
> be considered pure. What has that got to do with the compiler being
> required to call it?
>
> I'd say a pure void function should be equivalent to no-op and elidable.
If it's elidable, it's as good as a bug in the program. Must be either a compile-time error or a special case. -- Andrei
|
Copyright © 1999-2021 by the D Language Foundation