Conversation

Replying to

Jup das ist leider der einzige (möglichst simple) Weg. Andere möglichkeit wäre den Timeout auszulagern und den i zu übergeben. Aber ist halt leider so :/ Unser Bruder

muss da echt los...

Replying to

and

Use `let` not `var`. I your brother worked hard to help get this into ES6, where it means that each iteration has its own binding environment, so the closure works as you want it to. Guten Abend!

Replying to

and

I didn’t realize that. So JavaScript declaration-site distinctions between let and var are the analog of C++ lambda-site distractions between capture by variable or by value.

Replying to

and

Of languages supporting mutability, only Haskell IORef t and ML t ref are voodoo-free in this tegard. There, identifiers are always bound to constants, and references must be explicitly read and written.

Replying to

and

This highlights that in an imperative language, the default loop form should be something like “for(i in 1 to 10) ...” with the semantic that each iteration has a distinct x binding, and no need to explain away why the i’s before and after the i++ are different i’s.

Replying to

and

i.e. C-style for loops are bad. I’ve been saying this to everyone who will listen for years. :)

Replying to

isn't this also about by-value vs. by-reference closure conversion? I find it confusing that JS has both.

Replying to

No, this isn't about that. Do you mean JS has both reference (object) and primitive (null undefined boolean number string) types? Thank Java for that one :-/. "Make it look like Java!"

Replying to

It should not be observable in JS (outside of devtools and pathological var-aliases-formal-parameter+arguments[i] usage) whether an implementation uses env capture, binding capture, heap-boxing a la Chez Scheme, etc.