Skip to content
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

Items which are arrays mistakenly give slices in hash or array lookup in Rakudo #2708

Closed
p6rt opened this issue Apr 9, 2012 · 5 comments
Closed

Comments

@p6rt
Copy link

p6rt commented Apr 9, 2012

Migrated from rt.perl.org#112362 (status was 'resolved')

Searchable as RT112362$

@p6rt
Copy link
Author

p6rt commented Apr 9, 2012

From @masak

<moritz> masak​: I think there's also an unsubmitted rakudobug in
today's backlog, kind of as a delayed Easter egg for you :-)
<pmichaud> there are probably a couple :)
<moritz> (I meant the one with %h{<a b>} vs. %h{[<a b>]}
<moritz> p6​: my %h = a => 1, b => 2, 'a b' => 3; say %h{[<a b>]}
<p6eval> pugs, niecza v15-6-gefda208​: OUTPUT«3␤»
<p6eval> ..rakudo 4373f0​: OUTPUT«1 2␤»
<moritz> looks like over-eager flattening to me
* masak submits rakudobug
<pmichaud> p6​: my @​a = 0..5; say @​a[ [2, 3] ]
<p6eval> pugs, niecza v15-6-gefda208​: OUTPUT«2␤»
<p6eval> ..rakudo 4373f0​: OUTPUT«2 3␤»
<pmichaud> I think rakudo might be right here.
<pmichaud> Since [2,3] is Positional, the result is a slice.
<masak> pmichaud​: I'll note that in the rakudobug.
<moritz> p6​: my @​a = 0..5; say @​a[ [2, 3], 0 ]
<p6eval> pugs​: OUTPUT«20␤»
<p6eval> ..niecza v15-6-gefda208​: OUTPUT«2 0␤»
<p6eval> ..rakudo 4373f0​: OUTPUT«2 3 0␤»
<moritz> pmichaud​: I'm pretty sure in this example rakudo is wrong
<pmichaud> I'm certain rakudo is wrong there.
<pmichaud> oh, wait, maybe not
<moritz> in general [] should never be implicitly flattened
<pmichaud> well, it's not really being flattened here.
<pmichaud> what's happening is that we're getting a slice of (@​a[
[2,3] ], @​a[0])
<moritz> it's been treated as two elements rathar than one. To me
that's flattening
<pmichaud> r​: my @​a = <a b c d e>; say @​a[ [2, 3], 0 ].perl
<p6eval> rakudo 4373f0​: OUTPUT«(("c", "d"), "a")␤»
<pmichaud> right
<pmichaud> it's not really "flattening"
<moritz> I'm pretty sure that's wrong too
<pmichaud> I'm not sure what "right" would be here.
<moritz> if it descends into [], then the return value shouldn't flatten
<pmichaud> you're saying that scalar-ness should trump Positional-ness
<moritz> yes
<moritz> well
<pmichaud> i.e., the fact that something is scalar should prevent it
from being treated as a Positional
<moritz> I'm not sure it should trump it, but at some level it should
be preserved at least
<masak> I think I agree.
<moritz> I find ('c', 'a') and (('c', 'd').item, 'a') acceptable outcomes
<TimToady> I only like the first
<moritz> though currently I think that the former makes more sense,
because .[] is not specced as hyper
<pmichaud> okay, so a Positional (or anything?) in a scalar container
shouldn't slice
<TimToady> I think only the first makes sense, because a subscript is
a LoL, and the second level list is still just a list, and [] doesn't
interpolate into it
<moritz> pmichaud​: anything in a scalar container shouldn't slice
<TimToady> the rules of list interpolation don't change just becuase
we're inside [1,2,3; 4,5,6; 7,8,9]
< pmichaud> this really doesn't have anything to do with list
interpolation, at least not in Rakudo's case.
<pmichaud> anyway, I can fix it now.

@p6rt
Copy link
Author

p6rt commented Apr 9, 2012

From @pmichaud

Now fixed in 2c9f46f. Needs spectests to close ticket.

Thanks,

Pm

@p6rt
Copy link
Author

p6rt commented Apr 9, 2012

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Apr 9, 2012

From @moritz

Now tested in S02-types/flattening.t.

@p6rt
Copy link
Author

p6rt commented Apr 9, 2012

@moritz - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant