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

» is no longer shuffled (<a b c d>».say) #5967

Open
p6rt opened this issue Jan 2, 2017 · 6 comments
Open

» is no longer shuffled (<a b c d>».say) #5967

p6rt opened this issue Jan 2, 2017 · 6 comments
Labels
severe A problem that is encountered frequently, or a problem that needs attention for other reasons

Comments

@p6rt
Copy link

p6rt commented Jan 2, 2017

Migrated from rt.perl.org#130485 (status was 'open')

Searchable as RT130485$

@p6rt
Copy link
Author

p6rt commented Jan 2, 2017

From @AlexDaniel

Code​:
<a b c d>».say

Result (2015.07)​:
d
b
c
a

Result (HEAD)​:
a
b
c
d

The idea was that the order of processing is not defined for » (though the results are returned in order), therefore it is a good idea to shuffle the results a little bit so that the user is not going to assume that » works like .map

Bisectable points to rakudo/rakudo@a519305

The commit description does not identify why the previous behavior was removed. Is it for performance reasons? Or did it just slip through the cracks?

Anyway, it would be nice to make it process things in some weird order. If the performance is such a big concern, then perhaps processing just one element (e.g. the first one) in a different order (as last) will probably save the problem for users yet won't introduce a noticeable performance hit.

This is part of a much larger discussion. See also Raku/doc#1107

@p6rt
Copy link
Author

p6rt commented Oct 7, 2017

From @AlexDaniel

<Zoffix> AlexDaniel​: FWIW jnthn++ said we'll likely make ». autothread only is pure routines, so no shuffling is really needed

On 2017-01-02 11​:31​:47, alex.jakimenko@​gmail.com wrote​:

Code​:
<a b c d>».say

Result (2015.07)​:
d
b
c
a

Result (HEAD)​:
a
b
c
d

The idea was that the order of processing is not defined for » (though
the results are returned in order), therefore it is a good idea to
shuffle the results a little bit so that the user is not going to
assume that » works like .map

Bisectable points to
rakudo/rakudo@a519305

The commit description does not identify why the previous behavior was
removed. Is it for performance reasons? Or did it just slip through
the cracks?

Anyway, it would be nice to make it process things in some weird
order. If the performance is such a big concern, then perhaps
processing just one element (e.g. the first one) in a different order
(as last) will probably save the problem for users yet won't introduce
a noticeable performance hit.

This is part of a much larger discussion. See also
Raku/doc#1107

@p6rt
Copy link
Author

p6rt commented Oct 7, 2017

From @AlexDaniel

<AlexDaniel_> Zoffix​: so <a b c d>».say should not be discouraged? Interesting
<Zoffix> AlexDaniel_​: well, that's based on an off-hand comment in IRC chat. Not a final design descision :)

On 2017-10-07 09​:32​:43, alex.jakimenko@​gmail.com wrote​:

<Zoffix> AlexDaniel​: FWIW jnthn++ said we'll likely make ». autothread
only is
pure routines, so no shuffling is really needed

On 2017-01-02 11​:31​:47, alex.jakimenko@​gmail.com wrote​:

Code​:
<a b c d>».say

Result (2015.07)​:
d
b
c
a

Result (HEAD)​:
a
b
c
d

The idea was that the order of processing is not defined for »
(though
the results are returned in order), therefore it is a good idea to
shuffle the results a little bit so that the user is not going to
assume that » works like .map

Bisectable points to

rakudo/rakudo@a519305

The commit description does not identify why the previous behavior
was
removed. Is it for performance reasons? Or did it just slip through
the cracks?

Anyway, it would be nice to make it process things in some weird
order. If the performance is such a big concern, then perhaps
processing just one element (e.g. the first one) in a different order
(as last) will probably save the problem for users yet won't
introduce
a noticeable performance hit.

This is part of a much larger discussion. See also
Raku/doc#1107

@p6rt
Copy link
Author

p6rt commented Oct 7, 2017

From @AlexDaniel

<TimToady> » is supposed to be an explicit promise that you don't care about order, and there are lots of places that are not marked pure that are nevertheless effectively pure

On 2017-10-07 09​:34​:59, alex.jakimenko@​gmail.com wrote​:

<AlexDaniel_> Zoffix​: so <a b c d>».say should not be discouraged?
Interesting
<Zoffix> AlexDaniel_​: well, that's based on an off-hand comment in IRC
chat.
Not a final design descision :)

On 2017-10-07 09​:32​:43, alex.jakimenko@​gmail.com wrote​:

<Zoffix> AlexDaniel​: FWIW jnthn++ said we'll likely make ».
autothread
only is
pure routines, so no shuffling is really needed

On 2017-01-02 11​:31​:47, alex.jakimenko@​gmail.com wrote​:

Code​:
<a b c d>».say

Result (2015.07)​:
d
b
c
a

Result (HEAD)​:
a
b
c
d

The idea was that the order of processing is not defined for »
(though
the results are returned in order), therefore it is a good idea to
shuffle the results a little bit so that the user is not going to
assume that » works like .map

Bisectable points to

rakudo/rakudo@a519305

The commit description does not identify why the previous behavior
was
removed. Is it for performance reasons? Or did it just slip through
the cracks?

Anyway, it would be nice to make it process things in some weird
order. If the performance is such a big concern, then perhaps
processing just one element (e.g. the first one) in a different
order
(as last) will probably save the problem for users yet won't
introduce
a noticeable performance hit.

This is part of a much larger discussion. See also
Raku/doc#1107

@p6rt
Copy link
Author

p6rt commented Jan 30, 2018

From @zoffixznet

On Sat, 07 Oct 2017 09​:38​:10 -0700, alex.jakimenko@​gmail.com wrote​:

<TimToady> » is supposed to be an explicit promise that you don't care
about
order, and there are lots of places that are not marked pure that are
nevertheless effectively pure

On 2017-10-07 09​:34​:59, alex.jakimenko@​gmail.com wrote​:

<AlexDaniel_> Zoffix​: so <a b c d>».say should not be discouraged?
Interesting
<Zoffix> AlexDaniel_​: well, that's based on an off-hand comment in
IRC
chat.
Not a final design descision :)

On 2017-10-07 09​:32​:43, alex.jakimenko@​gmail.com wrote​:

<Zoffix> AlexDaniel​: FWIW jnthn++ said we'll likely make ».
autothread
only is
pure routines, so no shuffling is really needed

On 2017-01-02 11​:31​:47, alex.jakimenko@​gmail.com wrote​:

Code​:
<a b c d>».say

Result (2015.07)​:
d
b
c
a

Result (HEAD)​:
a
b
c
d

The idea was that the order of processing is not defined for »
(though
the results are returned in order), therefore it is a good idea
to
shuffle the results a little bit so that the user is not going to
assume that » works like .map

Bisectable points to

rakudo/rakudo@a519305

The commit description does not identify why the previous
behavior
was
removed. Is it for performance reasons? Or did it just slip
through
the cracks?

Anyway, it would be nice to make it process things in some weird
order. If the performance is such a big concern, then perhaps
processing just one element (e.g. the first one) in a different
order
(as last) will probably save the problem for users yet won't
introduce
a noticeable performance hit.

This is part of a much larger discussion. See also
Raku/doc#1107

More details on this​:

We actually still fake-shuffle non-nodal hypers, because those we handle with &nodemap,
while nodal ones use &deepmap. Also, &deepmap currently can handle lazy iterables,
while &nodemap can't.

Both are bit underspecced[^1] but looks like this Issue goes beyond just shuffling results
and needs to change &nodemap to be eager too (IIRC all hypers imply eagerness)

  $ ./perl6 -e '(lazy <a b c>)».uc'

  $ ./perl6 -e '(lazy <a b c>)».elems'
  Cannot nodemap a lazy list
  in block <unit> at -e line 1

  $ ./perl6 -v
  This is Rakudo version 2018.01-57-g4d2b54ebe built on MoarVM version 2018.01-49-g783a4f07c
  implementing Perl 6.c.

[1] Raku/roast#370

@p6rt
Copy link
Author

p6rt commented Jan 30, 2018

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

@p6rt p6rt added the severe A problem that is encountered frequently, or a problem that needs attention for other reasons label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
severe A problem that is encountered frequently, or a problem that needs attention for other reasons
Projects
None yet
Development

No branches or pull requests

1 participant