On Thu, 21 Jul 2016 09:20:38 -0700, ajs wrote:
> The core issue is this simple code:
>
> my @a = lazy gather { say 'we actually run' }; sink @a;
>
> Which gives:
>
> OUTPUT«WARNINGS for <tmp>:Useless use of @a in sink context (line 1)we
> actually run»
>
> Note that if you insert "quietly" before sink, it still gives the warning,
> which is also questionable.
>
> From the discussion on IRC:
>
>
> [11:59] <harmil> Speaking of sink, I'm not convinced that the warning for
> useless use of iterables in sink context should be a thing. e.g.:
> [11:59] <harmil> m: sink ^1000
> [11:59] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for <tmp>:Useless
> use of "^" in expression "^1000" in sink context (line 1)»
> [12:00] <harmil> I'm explicitly asking for the expansion of the sequence to
> be performed and ignored. That's not something that should get a warning,
> is it?
> [12:00] <jnthn> I don't think it's a warning for iterables in general
> [12:00] <jnthn> It's for a useless use of the (known pure) range constructor
> [12:01] <jnthn> m: sink 1, 1, *+* ... 8
> [12:01] <+camelia> rakudo-moar 86843a: ( no output )
> [12:01] <jnthn> Note no warning there
> [12:02] <harmil> m: my @foo = 1,1,*+*...8; sink @foo
> [12:02] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for <tmp>:Useless
> use of @foo in sink context (line 1)»
> [12:03] <jnthn> The assignment to the array is already eager in that case
> [12:05] <harmil> jnthn: that's not why we get the warning. I won't do the
> version with 8 replaced by * as it never terminates, but it also gives the
> warning.
> [12:06] <unmatched}> m: sink 1, 1, *+* ... *
> [12:06] <+camelia> rakudo-moar 86843a: OUTPUT«Memory allocation failed;
> could not allocate 1146880 bytes»
> [12:06] <jnthn> m: my @foo = 1,1,*+*...8; sink @foo;
> [12:06] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for <tmp>:Useless
> use of @foo in sink context (line 1)»
> [12:06] <jnthn> But that terminates.
> [12:07] <harmil> It just feels to me as if "sink" means "just do it" and
> getting a warning that "it" isn't useful just doesn't sit well with me.
> YMMV.
> [12:08] <jnthn> It's not telling you it isn't useful, it's telling you
> there's nothing to do and you wrote dead code.
> [12:09] <jnthn> Which the vast majority of the time implies a confused
> programmer.
> [12:09] <harmil> Except it doesn't know that. @a might be anything, and
> iterating over it might be extremely useful (e.g. it might do a full read
> from a DB, and I might be timing that)
> [12:09] <unmatched}> m: quietly sink ^1000
> [12:09] <+camelia> rakudo-moar 86843a: ( no output )
> [12:10] <jnthn> m: my @a = lazy gather { say 'we actually run' }; sink @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for <tmp>:Useless
> use of @a in sink context (line 1)we actually run»
> [12:10] <harmil> Nice example.
> [12:10] <unmatched}> m: my @a = lazy gather { say 'we actually run' };
> quietly sink @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for <tmp>:Useless
> use of @a in sink context (line 1)we actually run»
> [12:10] <jnthn> Yeah, that one is more interesting, but now I want to know
> why the ... one up above didn't hang
> [12:10] <unmatched}> m: my @a = lazy gather { say 'we actually run' }; sink
> quietly @a
> [12:10] <+camelia> rakudo-moar 86843a: OUTPUT«WARNINGS for <tmp>:Useless
> use of @a in sink context (line 1)we actually run»
> [12:11] <jnthn> oh wait, 'cus I wrote it wrong
> [12:11] <unmatched}> Interesting.
> [12:11] <jnthn> m: my @foo = 1,1,*+*...*; sink @foo;
> [12:11] <+camelia> rakudo-moar 86843a: OUTPUT«(signal SEGV)WARNINGS for
> <tmp>:Useless use of @foo in sink context (line 1)»
> [12:11] <jnthn> Yeah, I'd agree on a variable it's rather dubious.
> [12:11] <harmil> You get the segv award!
> [12:12] <jnthn> On sink ^1000 I think it's spot on
> [12:12] <harmil> Yeah, at best ^n is just a weird sort of timing test, and
> I could reasonably expect to have to quiet that manually.
> [12:12] <jnthn> But yeah, feel free to file it against the @foo case. That
> does look a bit bogus
> [12:12] <harmil> And I might expect that the optimizer would not be my
> friend there
>
> --
> Aaron Sherman, M.:
> P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com
> Toolsmith, developer, gamer and life-long student.
Thank you for the report. This is now fixed.
Fix: https://github.com/rakudo/rakudo/commit/99da4a5a6c45244
Test: https://github.com/rakudo/rakudo/commit/99da4a5a6c45244
