The attitude towards <i>goto</i> really struck a chord with me. It's "powerful" and "easy to explain". It's also "simple" to add to the VM. It's in, and purity be damned.<p>There's something to be said here about pragmatism versus purity. Maybe also a comparison with the recent posts about OO and Rails. I'm hand-waving. I mean to write something longer about this, but I'm still trying to decide what exactly I make of it.
For anyone wondering about "C upvalues", which wasn't clear to me, there is some explanation here:<p><a href="http://www.lua.org/pil/27.3.3.html" rel="nofollow">http://www.lua.org/pil/27.3.3.html</a><p>Essentially, they are unbound variables that have to be reachable from the function by some mechanism, making it a closure.<p>Apologies if I've misunderstood anything here.
I think it is worth to mention:<p>Structured programming with go to statements (1974) by Donald E. Knuth (<a href="http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.6084" rel="nofollow">http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.6...</a>)
What this leaves me wondering is : what are the continuation semantics for the gotos? Without that part it's hard to know if "ill formed" gotos that result in trying to execute expressions with undefined variables can happen or not.
can someone smarter than me comment on whether delimited continuations are better or worse than goto and/or "ordinary" continuations? (because i suspect they are nicer in how they handle scope, and they are what are typically implemented, aren't they?)