Hacker News Reader

Comment by k__ | Hacker News Reader

will the spread operator really evaluate the generator lazily?

Pretty sure it will not. Nothing is lazy in JS by default:

> One caveat of spreading iterables: JavaScript creates an array out of the elements of the iterable. That might be very wasteful for extremely large collections. For example, if we spread a large collection just to find an element in the collection, it might have been wiser to iterate over the element using its iterator directly.

> And if we have an infinite collection, spreading is going to fail outright.

http://raganwald.com/2015/02/17/lazy-iteratables-in-javascri...

Steelbrain’s use of the async for loop is indeed lazy.

> Pretty sure it will not. Nothing is lazy in JS by default:

It really depends on the logic written. You can solve the same thing in many different ways, the way chosen by the author doesn't seem to be a lazy one.

Not the language's fault. It's simply doing what is asked of it.

Eg, see https://news.ycombinator.com/item?id=24265507

Yes, I thought so too.

If they spread anyway, they could leave the generator away in the first place.

I was just confused, why use a generator when you spread it anyway.

I don't think any language has a lazy spread operator. Haskell is the only language I know off lazy enough to conceivably have one, but it doesn't accept arbitrary lists of arguments (unless you count having an actual list as an argument, which is the better option if you want laziness really).

Reply on news.ycombinator.com