It’s basically dynamic scoping problem. Unlabeled break/continue may not be intended for closest dynamically enclosing break/cont-able loop
-
-
Not dynamic scope: a dead outer activation causes return from block lambda to throw. Dynamic scope analogy would be return from unrelated!
1 reply 1 retweet 3 likes -
Replying to @BrendanEich @ljharb and
let b= ƛ(v){if (v) break; else continue}; are these different: forEach(c, b); forEach(c, ƛ(v){if (v) break; else continue});
3 replies 0 retweets 2 likes -
Correspondence principle deal is program equivalence: while(1)break === while(1)({|| break})(). Variable abstraction independent/composes.
1 reply 0 retweets 1 like -
Replying to @BrendanEich @ljharb and
Too hard to show on twitter. Have to get into guts of forEach, etc. to show how they compose. My pdf was a start.
1 reply 0 retweets 1 like -
Yes, agree this exposes/specifies “guts” - one reason among several that block lambdas failed.
1 reply 0 retweets 2 likes -
Replying to @BrendanEich @awbjs and
Give me another chance and I'll fight my ass off. Otherwise, the frequent justifications for the decision aren't that helpful.
2 replies 0 retweets 2 likes -
Read closely, justifications strong. No way: dynamic throw-like return/break/continue. Static better but dead frame return throws hazardous.
1 reply 0 retweets 2 likes -
Replying to @BrendanEich @awbjs and
You have to do better than "return from dead frame hazardous" when Ruby has the same hazard and doesn't create too much confusion.
3 replies 0 retweets 2 likes -
I don’t have to do better cuz JS lacks that runtime test-coverage dependent hazard vs Ruby. Don’t assume Ruby is self-evident gold standard.
2 replies 0 retweets 1 like
Ruby is used by noobs who are broadly not confused. That's all I'm using ruby as evidence for.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.