On Sat, 07 Oct 2017 09:38:10 -0700, alex.jakime...@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.jakime...@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.jakime...@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.jakime...@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
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] https://github.com/perl6/roast/issues/370
