[perl #130485] [SEVERE] » is no longer shuff led (<a b c d>».say)

[email protected] ("Zoffix Znet via RT")
Newsgroups perl.perl6.compiler
Message-ID <[email protected]>
On Sat, 07 Oct 2017 09:38:10 -0700, [email protected] 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, [email protected] 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, [email protected] 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, [email protected] 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.