｢my @a = 1 … 9999999｣ is not lazy, explain it somewhere

[AlexDaniel]

This is a continuation of RT #130480.

Our docs say:

The sequence operator is a generic operator to produce lazy lists.

Well, is it? Seems like it produces Seq-s, not lazy lists. Lazy lists can be obtained, for example, from .list-ing a Range (.. operator, not ...), or by lazy-ing a Seq.

And getting back to the ticket:

my @a = 1 … 9999999

↑ This is not lazy at all. But with our current documentation it is fair to assume that it should be lazy.

We should improve our docs on … first. Then perhaps document another trap?

[AlexDaniel]

Ah, another thing to note is that this is actually lazy:

my @a = 1 … ∞

Also, some discussion: https://irclog.perlgeek.de/perl6/2017-01-02#i_13836946

[JJ]

👍

[gfldex]

my \a = 1 … 9999999;
Is also lazy. This should go into containers with a link from ....

[JJ]

Is there a minimum number for which a Seq turns eager? Is that maybe in the Rakudo code?

[AlexDaniel]

Minimum number? No.

[JJ]

Well, the documentation says it produces lazy lists. I guess that's all wrong.
But what's the alternative? It produces lazy lists when it's used outside a variable or when numbers are humongous? Is there a test for that in roast?

[JJ]

There are a few tests in roast. Let me see what I can glean from that.

[tisonkun]

But what's the alternative?

FWIW

> (1 … 9999999).is-lazy
False
> (1 … 9999999).lazy.is-lazy
True

[JJ]

Lazy lists are only generated by … if the endpoint is infinity. I just changed that in the documentation. Please check that it's correct now. It was simply wrong in the initial description.

[AlexDaniel]

No-no that's not really closed. Here are some ramblings.

humongous

It's not about the size, it is always as lazy as possible. The difference between Inf and non-Inf endpoint seems to be that it's just special-cased differently.

I have no idea how to explain this, but as far as I can understand … operator gives you a Seq. If you call .cache on it, then you'll get a lazy List. Difference being that Seq can only spit values at you, like when you're iterating it, but you cannot access the same item again. Or that's what I thought. Take a look at this: https://irclog.perlgeek.de/perl6/2018-04-20#i_16071038

So basically I guess I don't know what a Seq is, and how it's different (if it is) from a List thingie.

As for is-lazy, it doesn't really give any meaningful results. It returns… something. See this for more info: https://github.com/rakudo/rakudo/wiki/is-lazy

[JJ]

I have described it according to the roast tests, which only return lazy sequences if the endpoint is */Inf. Please check out the new description, flag what's wrong and change the issue accordingly, because according to the roast test, 1 … 9999999 should never be lazy.

[AlexDaniel]

Still not right, it doesn't matter if the endpoint is Inf or not, everything will be generated on demand.

Try something like this maybe to see it: my $x := (0, {say “I’m here $_”; $_ + 1} … 42); say $x[3]

[zoffixznet]

My 2¢: use term "lazy" less.

It's really adds a lot of confusion as it can mean "values generated on-demand" (as opposed to right-away) and all of our Seqs are like that, and it can also mean "infinite-like", which is what .is-lazy flag represents. Generally, infinite-like Seqs are meant to be treated as if they're infinite because trying to reify them right away would be bad (i.e. with actual infinite Seqs, that'd mean consuming all CPU; IO::Path.lines gives an infinite-like Seq and even though it's not really infinite, reifying it all at once into a @ variable could mean consuming all of the RAM if the file is huge; etc.)

• The … always produces Seqs that produce values on-demand, but only certain end points would also mark those Seqs as infinite-like
• Assignment to @ is "mostly-eager" and will reify Seqs immediately, unless they're infinite-like, in which case it'll reify them only on-demand

Here's an example that shows this. The first Seq has a * endpoint, so it's infinite-like (marked as .is-lazy) and you can see assigned is printed before reifying: The second Seq only goes up to 3 so it's not infinite-like and the assignment reifies it right away,

$ perl6 -e 'my @a = {say "reifying"; ++$} … *; say "assigned"; say @a[^2]'
assigned
reifying
reifying
(1 2)

$ perl6 -e 'my @a = {say "reifying"; ++$} … 3; say "assigned"; say @a[^2]'
reifying
reifying
reifying
assigned
(1 2)

You can also force non-infinite-like Seqs to be treated as infinite-like with the lazy routine call:

$ perl6 -e 'my @a = lazy ({say "reifying"; ++$} … 3); say "assigned"; say @a[^2]'
assigned
reifying
reifying
(1 2)

And you can see that it's the assignment to @ var that causes immediate reification of non-infinite-like Seqs and that they normally produce values on-demand with this example:

my $s := ({say "reifying"; ++$} … 3); say "assigned"; say $s[^2]'
assigned
reifying
reifying
(1 2)

"assigned" is printed before any values were generated.

[JJ]

2018-04-20 18:39 GMT+02:00 Zoffix Znet <notifications@github.com>:

My 2¢: use term "lazy" less. It's really adds a lot of confusion as it can mean "values generated on-demand" (as opposed to right-away) and all of our Seqs are like that, and it can also mean "infinite-like", which is what .is-lazy flag represents. - The … always produces Seq that produce values on-demand - Assignment to @ is "mostly-eager" and will reify Seqs immediately, unless they're infinite-like, in which case it'll reify them only on-demand

But assignment is outside the scope of this particular issue and paragraph. Such as it is now, it does avoid mentioning "lazy" in favor of "on demand".

Here's an example that shows this. The first Seq has a * endpoint, so it's infinite-like (marked as .is-lazy) and you can see assigned is printed before reifying: The second Seq only goes up to 3 so it's not infinite-like and the assignment reifies it right away, $ perl6 -e 'my @A = {say "reifying"; ++$} … *; say "assigned"; say @A[^2]' assigned reifying reifying (1 2) $ perl6 -e 'my @A = {say "reifying"; ++$} … 3; say "assigned"; say @A[^2]' reifying reifying reifying assigned (1 2) You can also force non-infinite-like Seqs to be treated as infinite-like with the lazy routine call: $ perl6 -e 'my @A = lazy ({say "reifying"; ++$} … 3); say "assigned"; say @A[^2]' assigned reifying reifying (1 2) And you can see that it's the assignment to @ var that causes immediate reification of non-infinite-like Seqs and that they normally produce values on-demand with this example: my $s := ({say "reifying"; ++$} … 3); say "assigned"; say $s[^2]' assigned reifying reifying (1 2) "assigned" is printed before any values were generated.

Maybe add "reification" to glossary and/or something to the traps page.

[zoffixznet]

Maybe add "reification" to glossary and/or something to the traps page.

It (or a form of it) is already there: https://docs.perl6.org/language/glossary#Reify
Doesn't show in search, presumably due to that indexing bug.

[JJ]

I didn't know that page was also affected...

[JJ]

Anyway, if no further work is needed on this particular issue, allow me to close it if you don't want to change the title or repurpose it for something else.