Skip Menu |
Report information
Id: 130485
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: alex.jakimenko [at] gmail.com
Cc:
AdminCc:

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



Subject: » is no longer shuffled (<a b c d>».say)
Download (untitled) / with headers
text/plain 958b
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 https://github.com/rakudo/rakudo/commit/a5193055bf4656cd8da67fde6e76a745458185fe 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 https://github.com/perl6/doc/issues/1107
<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:
Show quoted text
> 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
> https://github.com/rakudo/rakudo/commit/a5193055bf4656cd8da67fde6e76a745458185fe
>
> 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
> https://github.com/perl6/doc/issues/1107


<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:
Show quoted text
> <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
> >
> https://github.com/rakudo/rakudo/commit/a5193055bf4656cd8da67fde6e76a745458185fe
> >
> > 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
> > https://github.com/perl6/doc/issues/1107


<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:
Show quoted text
> <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
> > >
> >
> https://github.com/rakudo/rakudo/commit/a5193055bf4656cd8da67fde6e76a745458185fe
> > >
> > > 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
> > > https://github.com/perl6/doc/issues/1107




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