Re: Map Lambda with Side-Effects
On Wednesday, 14 January 2015 at 01:15:57 UTC, Tobias Pankrath wrote: Is it possible to - detect that a lambda is has-side-effects and that - the map hasn't been used? Thing is: I'm regularly doing that on purpose. Could you show me a code example? I'm curious. Actually, isn't your closure even weakly pure in your example, because arr is part of the closure and thus an argument to it. I'm fully understand the meaning of weakly and strongly pure functions in D. However I'm not enough familiar with closure purity semantics in D. Could you elaborate a bit, please?
Re: Map Lambda with Side-Effects
Is it possible to - detect that a lambda is has-side-effects and that - the map hasn't been used? Thing is: I'm regularly doing that on purpose. Actually, isn't your closure even weakly pure in your example, because arr is part of the closure and thus an argument to it.
Re: Map Lambda with Side-Effects
On Tuesday, 13 January 2015 at 10:21:12 UTC, Tobias Pankrath wrote: On Tuesday, 13 January 2015 at 10:06:26 UTC, bearophile wrote: Nordlöw: Has there been any discussions on making map require pure functions now that we have each? Perhaps I'd like Phobos map and filter to be annotated with pure and to have a template constraint that requires their mapping/filtering functions to be strongly pure. Bye, bearophile Please not. It should be obviously documented that the number of applications of the function is not limited to once-per-element and that evaluation doesn't necessarily happen in-order. I forget and am re-reminded of this once every few months, despite how central it is to ranges in general. It can still be useful to use impure functions with it though, as long as you consider what is actually going on.
Re: Map Lambda with Side-Effects
On Tue, 13 Jan 2015 10:06:25 + bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Nordlöw: Has there been any discussions on making map require pure functions now that we have each? Perhaps I'd like Phobos map and filter to be annotated with pure and to have a template constraint that requires their mapping/filtering functions to be strongly pure. that will effectively rule out any usage of some global vars or other external state, turning it into either unnecessary mess, or unusable theoretical crap. what i think should be written in big red letters in docs is there is no guarantees about how many times labmda will be called, with which args and in which order. so if someone wants to shoot in his foot, he can ignore that warning and do crazy shooting. signature.asc Description: PGP signature
Re: Map Lambda with Side-Effects
Nordlöw: Has there been any discussions on making map require pure functions now that we have each? Perhaps I'd like Phobos map and filter to be annotated with pure and to have a template constraint that requires their mapping/filtering functions to be strongly pure. Bye, bearophile
Re: Map Lambda with Side-Effects
On Tue, 13 Jan 2015 11:26:01 + bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: ketmar: that will effectively rule out any usage of some global vars or other external state, turning it into either unnecessary mess, or unusable theoretical crap. Unusable theoretical crap is better than the current trap :-) in no way. this just turns Phobos into the same unusable crap, removing the whole sense of having good standard library. We hare pure in D, but still we have not grown up to actually use it in Phobos, for higher order functions, or parallelism. let an user choose if he wants pure or impure HOF args. just make a big warning in documentation about unpredictability of HOFs with side-effects and this will be enough, i believe. signature.asc Description: PGP signature
Re: Map Lambda with Side-Effects
On Tuesday, 13 January 2015 at 10:06:26 UTC, bearophile wrote: Nordlöw: Has there been any discussions on making map require pure functions now that we have each? Perhaps I'd like Phobos map and filter to be annotated with pure and to have a template constraint that requires their mapping/filtering functions to be strongly pure. Bye, bearophile Please not.
Re: Map Lambda with Side-Effects
ketmar: that will effectively rule out any usage of some global vars or other external state, turning it into either unnecessary mess, or unusable theoretical crap. Unusable theoretical crap is better than the current trap :-) We hare pure in D, but still we have not grown up to actually use it in Phobos, for higher order functions, or parallelism. Bye, bearophile
Re: Map Lambda with Side-Effects
Unusable theoretical crap is better than the current trap :-)
We hare pure in D, but still we have not grown up to actually
use it in Phobos, for higher order functions, or parallelism.
I don't think that Nordlöw presented a serious trap. This might
lead to bugs, yes, like anything else, for example: void
foo(int[] arr) { ... arr ~= ... }
Same error, if you expect arr to be changed outside the function.
In the case of Nordlöw: If you add a warning* it will issue many
warnings for a huge amount of perfectly fine code making the
warning useless. Forbidding it, would be even worse (since the
code wouldn't work, a more verbose alternative needs to be used
etc ..). For what? To prevent a possible bug that is easily found
and fixed? Wrong trade-off if you ask me.
* When should the warning actually be issued? Whenever a closure
is passed to map? Whenever a closure passed to map closes over
something where hasAliasing!T is true?
Re: Map Lambda with Side-Effects
ketmar: in no way. this just turns Phobos into the same unusable crap, removing the whole sense of having good standard library. If your language has purity, and it doesn't use it where it matters, you have removed its sense of having purity. So if you are right then purity in D is useless and Rust has chosen better than D on this. Bye, bearophile
Re: Map Lambda with Side-Effects
On Tuesday, 13 January 2015 at 07:35:53 UTC, Nordlöw wrote:
Somewhat related to
https://github.com/D-Programming-Language/phobos/pull/2024
I wonder about the soundness of `map` in
```D
import std.algorithm, std.range, std.stdio;
void main(string[] args)
{
long[] arr;
const n = 3;
iota(n).map!(a = arr ~= a);
writeln(arr);
writeln(iota(n).map!(a = arr ~= a));
writeln(arr);
}
```
that prints
```D
[]
[[0], [0, 1], [0, 1, 2]]
[0, 1, 2]
```
Shouldn't a warning at least be issued for return-ignoring calls
to map with mutating lambdas? Has there been any discussions on
making map require pure functions now that we have each? I guess
a new function, say `mapPure`, may be neccessary as adding such
a
restriction to the lambda will break too much code right?
To clarify:
I f() is stronly pure function then DMD since 2.066 will warn
about
f();
, that is, upon return-discarding calls to strongly pure function.
I believe
iota(n).map!(a = arr ~= a);
is a very similar mistake done and if possible should be warned
about.
Is it possible to
- detect that a lambda is has-side-effects and that
- the map hasn't been used?
If this can't (yet) be detected in compiled-time what about
issuing an exception in the destructor of Map to detect this?
Destroy!
Map Lambda with Side-Effects
Somewhat related to
https://github.com/D-Programming-Language/phobos/pull/2024
I wonder about the soundness of `map` in
```D
import std.algorithm, std.range, std.stdio;
void main(string[] args)
{
long[] arr;
const n = 3;
iota(n).map!(a = arr ~= a);
writeln(arr);
writeln(iota(n).map!(a = arr ~= a));
writeln(arr);
}
```
that prints
```D
[]
[[0], [0, 1], [0, 1, 2]]
[0, 1, 2]
```
Shouldn't a warning at least be issued for return-ignoring calls
to map with mutating lambdas? Has there been any discussions on
making map require pure functions now that we have each? I guess
a new function, say `mapPure`, may be neccessary as adding such a
restriction to the lambda will break too much code right?
