On Friday, 23 December 2016 at 20:01:49 UTC, Andrei Alexandrescu
wrote:
$(P Destructors will always be called even if they appear to be
strongly pure.)
Any other special functions we should worry about?
Andrei
Why ?
On 12/23/2016 02:32 PM, Andrei Alexandrescu wrote:
On 12/23/2016 01:53 PM, Johan Engelen wrote:
Perhaps I read this wrong but: the paragraph says that non-strongly-pure
functions receive no special treatment, but then the next paragraph adds
special treatment for a subset of non-strongly-pure
On 12/23/2016 01:53 PM, Johan Engelen wrote:
Perhaps I read this wrong but: the paragraph says that non-strongly-pure
functions receive no special treatment, but then the next paragraph adds
special treatment for a subset of non-strongly-pure functions... :)
Fixed. Keep destruction coming. --
On Friday, 23 December 2016 at 17:42:40 UTC, Andrei Alexandrescu
wrote:
On 12/23/2016 12:32 PM, Johan Engelen wrote:
On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu
wrote:
Instead of
"Any `pure` function
On 12/23/2016 12:32 PM, Johan Engelen wrote:
On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu
wrote:
Instead of
"Any `pure` function that is not strongly pure cannot be memoized."
why not
"Any `pure`
On Thursday, 22 December 2016 at 20:53:37 UTC, deadalnix wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu wrote:
Instead of
"Any `pure` function that is not strongly pure cannot be
memoized."
why not
"Any `pure` function that is not strongly pure _may not be
On Friday, December 23, 2016 14:12:54 Observer via Digitalmars-d wrote:
> On Friday, 23 December 2016 at 11:11:09 UTC, Jonathan M Davis
>
> wrote:
> > Conceptually, it makes no sense to be doing any of that sort of
> > thing in a strongly pure function, because at that point, we're
> > really
On Friday, 23 December 2016 at 11:11:09 UTC, Jonathan M Davis
wrote:
Conceptually, it makes no sense to be doing any of that sort of
thing in a strongly pure function, because at that point, we're
really talking functional purity.
I understand your points. I had been thinking about purity
On Thursday, December 22, 2016 18:04:51 Observer via Digitalmars-d wrote:
> It seems to me that a pure function could have a variety of
> acceptable side effects which don't modify active memory and
> that don't work around the type system or necessarily eat
> significant CPU time, and that you
On Friday, December 23, 2016 07:29:49 Stefan Koch via Digitalmars-d wrote:
> On Friday, 23 December 2016 at 06:53:25 UTC, Observer wrote:
> [ ... ]
>
> A pure function MUST NOT mutate any state except what is
> reachable through it's arguments.
> This includes ANY operating system state.
That's
On Friday, 23 December 2016 at 06:53:25 UTC, Observer wrote:
[ ... ]
A pure function MUST NOT mutate any state except what is
reachable through it's arguments.
This includes ANY operating system state.
As for your debugger point.
You can break on a pure function as well as on any other.
And,
On Thursday, 22 December 2016 at 18:49:02 UTC, Stefan Koch wrote:
On Thursday, 22 December 2016 at 18:04:51 UTC, Observer wrote:
(1) Serve as a convenient breakpoint handle in the debugger,
perhaps
as a kind of centralized this_cannot_ever_happen()
function.
(2)
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu wrote:
Instead of
"Any `pure` function that is not strongly pure cannot be
memoized."
why not
"Any `pure` function that is not strongly pure _may not be
assumed to
be_ memoizable."
Got it. Good point. Will do.
That
On Thursday, 22 December 2016 at 18:04:51 UTC, Observer wrote:
(1) Serve as a convenient breakpoint handle in the debugger,
perhaps
as a kind of centralized this_cannot_ever_happen() function.
(2) conditionally_die(conditions);
(3) Sleep for some run-time-computable length of time.
(4)
On Wednesday, 21 December 2016 at 01:05:50 UTC, Jonathan M Davis
wrote:
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 --
On 12/22/2016 11:45 AM, Johan Engelen wrote:
On Wednesday, 21 December 2016 at 22:08:58 UTC, Andrei Alexandrescu wrote:
Well randomness is not available in pure functions.
Internet discussions... a misunderstanding, I should've been more careful.
I meant "an arbitrary boolean value", not
On Wednesday, 21 December 2016 at 22:08:58 UTC, Andrei
Alexandrescu wrote:
Well randomness is not available in pure functions.
Internet discussions... a misunderstanding, I should've been more
careful.
I meant "an arbitrary boolean value", not something random (e.g.
the version(LDC) thing).
On 12/21/2016 04:42 PM, Johan Engelen wrote:
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei Alexandrescu wrote:
On 12/21/2016 03:04 PM, Johan Engelen wrote:
Super contrived, but I hope you get my drift:
```
int *awesome() pure {
static if (ohSoAwesome) {
return new int;
}
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu wrote:
On 12/21/2016 03:04 PM, Johan Engelen wrote:
Super contrived, but I hope you get my drift:
```
int *awesome() pure {
static if (ohSoAwesome) {
return new int;
} else {
return null;
}
}
```
Where does
On Wednesday, 21 December 2016 at 21:34:04 UTC, Andrei
Alexandrescu wrote:
On 12/21/2016 03:04 PM, Johan Engelen wrote:
```
I don't know what "required to honor all calls" means, but I
guess it means
```
auto a = foo(); // int* foo() pure;
auto b = foo();
```
cannot be transformed to
```
On 12/21/2016 03:59 PM, John Colvin wrote:
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function
On 12/21/2016 03:10 PM, Johan Engelen wrote:
On Wednesday, 21 December 2016 at 20:04:04 UTC, Johan Engelen wrote:
"Any `pure` function that is not strongly pure _may not be assumed
to be_ memoizable."
That version of mine is also not correct :(
How about: "A strongly pure function can be
On 12/21/2016 03:04 PM, Johan Engelen wrote:
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
I think you
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that accepts only parameters without mutable
On Wednesday, December 21, 2016 15:49:35 Stefan Koch via Digitalmars-d
wrote:
> On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
>
> Alexandrescu wrote:
> > On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
> >> https://github.com/dlang/dlang.org/pull/1528 -- Andrei
> >
> > Dropped the
On Wednesday, 21 December 2016 at 20:04:04 UTC, Johan Engelen
wrote:
"Any `pure` function that is not strongly pure _may not be
assumed to be_ memoizable."
That version of mine is also not correct :(
How about: "A strongly pure function can be assumed to be
memoizable. For a not strongly
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
I think you should be very careful in making sure that
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that accepts only parameters without mutable
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that accepts only parameters without mutable indirections and
returns a result that has mutable indirections is called a
On 12/21/2016 05:08 AM, Timon Gehr wrote:
On 21.12.2016 01:58, 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
On 21.12.2016 01:58, 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
On Wednesday, 21 December 2016 at 02:27:02 UTC, Andrei
Alexandrescu wrote:
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
I can't see it ending well to make it this kind of special case.
For example, one day someone
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
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
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
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
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
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
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
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
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
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
42 matches
Mail list logo
