Oh man, Scratch's loop constructs are even weirder than I realized.

I thought there was always a 1-frame delay between iterations. Turns out that's not quite true?

Notice that without the "move" block inside the loop, the variable updates instantaneously.

Aha!

While executing scripts it "keeps a note of when one of them executed a block that can (potentially) change something on-screen"
…
"If it did NOT execute such a block, OR if it is in turbo mode, then Scratch will NOT (usually) wait for the next screen refresh"

Why do I care? Well, just for fun I'm trying to build a little JS library that implements Scratch's semantics as closely as possible.

(There are many like it, but this one is mine. 🤗)

The `yields` and `function *`s are a bit clunky.

If I'm going for a close mapping to Scratch, rather than something like looks like idiomatic JS, maybe a fluent API is nicer?

Progress!

Yields inside a `repeat` are actually working properly now: if you make any changes to the scene, the next iteration doesn't run until the following frame.

(Will release something soon!)

I also wrote up a TIL about Scratch's looping semantics
→ github.com/pdubroy/til/bl…