www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Map Lambda with Side-Effects

reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
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?
Jan 12 2015
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 13 2015
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
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.
Jan 13 2015
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
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.
Jan 13 2015
prev sibling parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Tue, 13 Jan 2015 10:06:25 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 Nordl=C3=B6w:
=20

 Has there been any discussions on
 making map require pure functions now that we have each?


=20
 Perhaps I'd like Phobos map and filter to be annotated with=20
 "pure" and to have a template constraint that requires their=20
 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.
Jan 13 2015
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 13 2015
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
 "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?
Jan 13 2015
prev sibling parent reply ketmar via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Tue, 13 Jan 2015 11:26:01 +0000
bearophile via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>
wrote:


 ketmar:
=20

 that will effectively rule out any usage of some global vars or=20
 other
 external state, turning it into either unnecessary mess, or=20
 unusable
 theoretical crap.


=20
 "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=20
 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.
Jan 13 2015
parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 13 2015
prev sibling parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
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!
Jan 13 2015
parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 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.
Jan 13 2015
parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
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?
Jan 15 2015