New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
:delete holes in Arrays get turned to Mus when coercing to List or Slip #6406
Comments
From @zoffixznetThe current behaviour kinda makes sense when you squint at it, but today we had a user[^1]who was surprised by it, so I'm filing it as a ticket, if maybe there's some Better Way this can be done with. When you :delete an element from the Array, you get nqp::null stuffed into the position, which gets converted to `is default` value when you look it up again: <Zoffix__> m: use nqp; my @a is default(42) = <a b c>; @a[1]:delete; dd @a However, if you now convert that Array to a Slip or a List, the hole is left as a bare Mu and doesn't get turned into a default value, which is lost: <Zoffix__> m: use nqp; my @a is default(42) = <a b c>; @a[1]:delete; dd @a.Slip <Zoffix__> m: use nqp; my @a is default(42) = <a b c>; @a[1]:delete; dd @a.List So it makes sense that without `is default` you don't get an `is default` value, but at the same time, Mu is not a great value to deal with... |
From @zoffixznetOn Sat, 22 Jul 2017 18:48:38 -0700, cpan@zoffix.com wrote:
And actually both .flat and .Seq do get `is default` value instead of Mu, so at the very least there's some inconsistency here: <Zoffix__> m: use nqp; my @a is default(42) = <a b c>; @a[1]:delete; dd @a.flat |
From @AlexDanielPerhaps also worth noting that this applies to other holes as well, e.g. those created by extending an array: my @a = 42; @a[5] = 49; say |@a # 42(Mu)(Mu)(Mu)(Mu)49 In fact, this the actual problem the user had. On 2017-07-22 18:52:03, cpan@zoffix.com wrote:
|
The RT System itself - Status changed from 'new' to 'open' |
From @lizmat
The problem is really caused by the fact that an Array has a descriptor, which contains the default value and type information, and a List does not. And since a Slip isa List, we lose the descriptor when Slipping an Array. The same issue appears with: $ 6 'my @a; @a[2] = 42; dd (|@a)[0] = 44; dd @a' Which is because Slip is a List, it uses List.AT-POS, and that one doesn’t create a WHENCE with a container to be filled at a later time. Which then goes back to: what is the use case of Slipping an Array? When do you need that? Perhaps slipping an Array should produce a warning? |
From @smls
Same as slipping any other type of Iterable: Fine-grained, elegant flattening and concatenating. Compare: my @all = flat $first, @rest; my @all = $first, |@rest; When you *know* that $first is a Scalar and @rest is an Array, those two do the same thing because `flat` doesn't descend into item containers. But if those are, say, function parameters, then they can become bound to other things, e.g. the calling code could pass a List to `@rest` which *doesn't* have its elements itemized, so the version with `flat` would destroy the elements' internal structure. Even if that wasn't the case, I'd consider the `|` version more elegant than the `flat` version, because it denotes very clearly to the reader *where* exactly something is being flattened into the outer list.
Couldn't `@array.Slip` be made to properly iterate @array behind the scenes (the same way that `@array.map` would iterate it), instead of reaching into @array's guts and copying its elements in a way that misinterprets some of them? |
From @lizmat
Which is exactly what 12d7d5b48add8347eb119 does. So fixed, and tests needed! |
From @zoffixznetOn Mon, 24 Jul 2017 01:54:53 -0700, elizabeth wrote:
Tests added in Raku/roast@24d5fcb486 However, the values for .List differ depending on how you access them. If you use iterator, you get a Mu for a hole, but if you use AT-POS you get a Nil.. 13:04 Zoffix m: (my @a)[1] = Mu; my @b is default(42) = @a.List; say @b I filed a separate ticket for that: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=132261 IRC: https://irclog.perlgeek.de/perl6-dev/2017-10-10#i_15283224 |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#131783 (status was 'resolved')
Searchable as RT131783$
The text was updated successfully, but these errors were encountered: