Skip Menu |
Report information
Id: 131162
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: elizabeth <liz [at] dijkmat.nl>
tomentiruran [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: .splice loses containerization on replacement value
To: rakudobug [...] perl.org
Date: Sun, 16 Apr 2017 21:56:20 +0200
Download (untitled) / with headers
text/plain 1.6k
Actually reported as a SO question by brian d foy: http://stackoverflow.com/questions/43437664/how-can-i-get-around-a-slurpy-parameter-in-the-perl-6-signature <lizmat> m: my @a = [1,1],[2,2],[3,3]; dd @a; @a.splice: 0, 2, $[4,4]; dd @a # feels like a bug that the containerization of [4,4] is being ignored <+camelia> rakudo-moar 188711: OUTPUT: «Array @a = [[1, 1], [2, 2], [3, 3]]␤Array @a = [4, 4, [3, 3]]␤» <jnthn> lizmat: Yeah, it's because there's a candidate with @new at the end that it binds to, decontainerizing it in the process. <jnthn> So it's not actually hitting the slurpy at all <lizmat> so you agree it's wrong atm <jnthn> The slurpy is **@foo <jnthn> So in fact if it *was* hitting the slurpy it would be behaving right :) <jnthn> Yeah, it's wrong to discard the itemization <lizmat> ok, so we are in agreement <jnthn> I wonder if it was untested and then accidentally regressed when splice was optimized by breaking it out into a bunch of candidates <lizmat> will file a rakudobug <jnthn> Since I seem to recall splice getting at least something of a look during the GLR <jnthn> And I can't imagine we settled on "it ignores itemization" :) <jnthn> bisectable6: my @a = [1,1],[2,2],[3,3]; @a.splice: 0, 2, $[4,4]; dd @a <+bisectable6> jnthn, On both starting points (old=2015.12 new=1887114) the exit code is 0 and the output is identical as well <+bisectable6> jnthn, Output on both points: «Array @a = [4, 4, [3, 3]]» <jnthn> Hm, nope <jnthn> It's been like that since Christmas <lizmat> ok, doesn't make it right, though :-) <jnthn> Indeed <lizmat> but will wait for the release to look at fixing it <jnthn> *nod*
To: rakudobug [...] perl.org
From: Andrew Buchanan <tomentiruran [...] gmail.com>
Subject: [BUG] Splicing Seq into array installs immutable values
Date: Sat, 9 Sep 2017 09:37:29 +0800
Download (untitled) / with headers
text/plain 13.6k
Download (untitled) / with headers
text/html 21.3k

Message body is not shown because it is too large.

Download (untitled) / with headers
text/plain 1.2k
On Fri, 08 Sep 2017 18:37:50 -0700, tomentiruran@gmail.com wrote: Show quoted text
>
> > my @h
> []
> > @h.splice: 0, 0, 1.Seq
> []
> > @h[0].VAR.WHAT
> (Int)
> > @h[0] = 5
> Cannot modify an immutable Int (1) > in block <unit> at <unknown file> line 1 > > I got hit by this with: @a.splice: 0, 0, Any xx 2
Good find. It's also not specific to `Seq` - it looks like it happens whenever the replacement elements are passed to `splice` as a nested structure rather than as flat arguments: my @h; @h.splice: 0, 0, 'a'; @h.splice: 1, 0, ('b',); dd @h; # Array @h = ["a", "b"] say @h[0].VAR.^name; # Scalar say @h[1].VAR.^name; # Str Conceptually¹⁺², the `splice` routine takes the replacements as a `*@` slurpy, so whether they're passed in nested or flat form should not matter. But Rakudo currently implements the routine with a `| is raw` signature: say Array.^find_method("splice").signature; # (Mu $: | is raw) ...and apparently does the parameter flattening manually, in a way that introduces this bug. Until it is fixed, a work-around is to flatten the replacement elements into the argument list of `splice` using `|`: @a.splice: 0, 0, |(Any xx 2); --- [1] https://docs.perl6.org/routine/splice [2] https://design.perl6.org/S32/Containers.html#splice
Subject: [BUG][GLR] .splice loses containerization on replacement value
Download (untitled) / with headers
text/plain 3.1k
On Sun, 16 Apr 2017 12:56:58 -0700, elizabeth wrote: Show quoted text
> Actually reported as a SO question by brian d foy: > > http://stackoverflow.com/questions/43437664/how-can-i-get-around-a- > slurpy-parameter-in-the-perl-6-signature > > > <lizmat> m: my @a = [1,1],[2,2],[3,3]; dd @a; @a.splice: 0, 2, > $[4,4]; dd @a # feels like a bug that the containerization of [4,4] > is being ignored > <+camelia> rakudo-moar 188711: OUTPUT: «Array @a = [[1, 1], [2, > 2], [3, 3]]␤Array @a = [4, 4, [3, 3]]␤» > <jnthn> lizmat: Yeah, it's because there's a candidate with @new at > the end that it binds to, decontainerizing it in the process. > <jnthn> So it's not actually hitting the slurpy at all > <lizmat> so you agree it's wrong atm > <jnthn> The slurpy is **@foo > <jnthn> So in fact if it *was* hitting the slurpy it would be behaving > right :) > <jnthn> Yeah, it's wrong to discard the itemization > <lizmat> ok, so we are in agreement > <jnthn> I wonder if it was untested and then accidentally regressed > when splice was optimized by breaking it out into a bunch of > candidates > <lizmat> will file a rakudobug > <jnthn> Since I seem to recall splice getting at least something of a > look during the GLR > <jnthn> And I can't imagine we settled on "it ignores itemization" :) > <jnthn> bisectable6: my @a = [1,1],[2,2],[3,3]; @a.splice: 0, 2, > $[4,4]; dd @a > <+bisectable6> jnthn, On both starting points (old=2015.12 > new=1887114) the exit code is 0 and the output is identical as well > <+bisectable6> jnthn, Output on both points: «Array @a = [4, 4, [3, > 3]]» > <jnthn> Hm, nope > <jnthn> It's been like that since Christmas > <lizmat> ok, doesn't make it right, though :-) > <jnthn> Indeed > <lizmat> but will wait for the release to look at fixing it > <jnthn> *nod*
This ticket and RT#132047 may be merged. Please find an experimental tree at: https://github.com/skids/rakudo/tree/rt131162 commit 998738620d1ca327e1b2d7727b7a0f28b9bce542 Author: skids <bri@abrij.org> Date: Fri Sep 15 21:01:48 2017 -0400 GLR-ize splice's @replacement argument Collapse **@ and @ candidates into +@ candidates. This is a spec/doc change. Will need to be reconciled. May need to figure out how to make this 6.d-only (or later) Amazingly, passes all spectests. Fixes RT#131162 and RT#132047 Needs ecosystem-wide testing for fallout (I also tried **@ and it did not fair very well. There are many specttests that assume single-argument-rule behavior on single arguments.) splice's prototype never got touched during GLR, if you look at git blame in specs. It just got missed, I guess. Probably not the only one. If someone who is tooled to do an ecosystem-wide/multiplatform test could try this tree we could get an idea how disruptive it would be. Figuring out where this sits WRT 6.d, both feature-wise and technically as to how we best replace 6.c's Array candidates or dispatcher. No performance tests have been done on this. I notice we still keep some core code doing +@ by hand but don't know if that is due to performance or just because they were implemented before we had that slurpy modifier, or due to a needed behavioral quirk.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org