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

List.pick doesn't flatten its invocant in Rakudo #2671

Closed
p6rt opened this issue Mar 13, 2012 · 7 comments
Closed

List.pick doesn't flatten its invocant in Rakudo #2671

p6rt opened this issue Mar 13, 2012 · 7 comments
Labels

Comments

@p6rt
Copy link

@p6rt p6rt commented Mar 13, 2012

Migrated from rt.perl.org#111732 (status was 'rejected')

Searchable as RT111732$

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 13, 2012

From @masak

<TimToady> perl6​: say (<[ ]> xx 10).pick(*).join
<p6eval> niecza v15-4-g1f35f89​: OUTPUT«[][[]][[][]]]][[[]][␤»
<p6eval> ..pugs b927740​: OUTPUT«[]]][[]]][[][][][[[]␤»
<p6eval> ..rakudo fee891​: OUTPUT«[][][][][][][][][][]␤»
<TimToady> rakudo feyl
<moritz> should it flatten all those parcels?
<TimToady> that's the default for most listy methods, which is why we need .lol
<TimToady> admittedly the spec could be clearer here
<TimToady> perl6​: say (<[ ]> xx 10).map(~*).join
<p6eval> ..rakudo fee891, niecza v15-4-g1f35f89​: OUTPUT«[][][][][][][][][][]␤»
<TimToady> you'll note rakudo flattens there, so it's being inconsistent
* masak submits (<[ ]> xx 10).pick(*).join rakuobug

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 9, 2013

From @masak

<masak> rn​: say (<0 1> xx 5).pick(*).join
<p6eval> rakudo 8ea992​: OUTPUT«0101010101␤»
<p6eval> ..niecza v24-33-gfc6d5fd​: OUTPUT«0101011010␤»
<masak> I'm with Niecza on this one -- any second opinion?
* jnthn tries to spot the problem
<jnthn> Oh...some flattening context thing?
<jnthn> rn​: say (<0 1> xx 5).flat.pick(*).join
<p6eval> rakudo 8ea992​: OUTPUT«0011100011␤»
<p6eval> ..niecza v24-33-gfc6d5fd​: OUTPUT«0100011011␤»
<masak> yeah.
* masak submits rakudobug

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 9, 2013

From @masak

<masak> rn​: say (<0 1> xx 5).roll
<p6eval> rakudo 8ea992, niecza v24-33-gfc6d5fd​: OUTPUT«0 1␤»
<masak> hm.
<jnthn> Well, I'll do the usual thing with flattening related tickets​:
wait for pmichaud++ to comment on the ticket ;)
<jnthn> I suspect this one should do what you expect though.
<masak> but Rakudo and Niecza agree on .roll -- that makes me uncertain
about .pick
<masak> because I always saw .pick() and .roll() as equivalent in
semantics.
<jnthn> *nod*
<masak> fwiw, my stance is that both .pick and .roll should select items
without regard for those pesky nested () thingies in my lists :)
<masak> but I have a feeling that if it were completely up to me, those
pesky nested () thingies would not be there at all...

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 9, 2013

@masak - Status changed from 'new' to 'open'

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented Oct 24, 2014

@usev6 - Status changed from 'new' to 'open'

Loading

@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2015

From @jnthn

On Sat Mar 09 13​:19​:02 2013, masak wrote​:

<masak> rn​: say (<0 1> xx 5).pick(*).join
<p6eval> rakudo 8ea992​: OUTPUT«0101010101␤»
<p6eval> ..niecza v24-33-gfc6d5fd​: OUTPUT«0101011010␤»
<masak> I'm with Niecza on this one -- any second opinion?
* jnthn tries to spot the problem
<jnthn> Oh...some flattening context thing?
<jnthn> rn​: say (<0 1> xx 5).flat.pick(*).join
<p6eval> rakudo 8ea992​: OUTPUT«0011100011␤»
<p6eval> ..niecza v24-33-gfc6d5fd​: OUTPUT«0100011011␤»
<masak> yeah.
* masak submits rakudobug

Rejecting this ticket, since we decided (as part of the GLR) that method call forms of list operations will not flatten.

Loading

@p6rt p6rt closed this May 1, 2015
@p6rt
Copy link
Author

@p6rt p6rt commented May 1, 2015

@jnthn - Status changed from 'open' to 'rejected'

Loading

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant