12 comments

[ 2.7 ms ] story [ 32.5 ms ] thread
The attitude towards goto 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.

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.

A lot of people wanted it is Lua is quite widely used as a code generation target, and generating gotos is useful often to match other language constructs.
For anyone wondering about "C upvalues", which wasn't clear to me, there is some explanation here:

http://www.lua.org/pil/27.3.3.html

Essentially, they are unbound variables that have to be reachable from the function by some mechanism, making it a closure.

Apologies if I've misunderstood anything here.

You got it. Quoting from the 5.2 manual:

  Because of the lexical scoping rules, local variables can
  be freely accessed by functions defined inside their scope.
  A local variable used by an inner function is called an
  upvalue, or external local variable, inside the inner
  function.
i.e., the external local variables the closure is closed on. And for C functions made available to Lua scripts:

  When a C function is created, it is possible to associate
  some values with it, thus creating a C closure (see
  lua_pushcclosure); these values are called upvalues and are
  accessible to the function whenever it is called.
- http://www.lua.org/manual/5.2/manual.html
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.
A label is visible in the entire block where it is defined (including nested blocks, but not nested functions).

A goto may jump to any visible label as long as it does not enter into the scope of a local variable.

This can be determined statically.

ok, so the semantics for lua goto's is to enter at the start of smallest enclosing block that has no free variables in the current environment? Or to statically reject code that tries to do so? That doesn't sound quite accurate, unless you're saying that lua does some static analysis before execution, which I was not aware of.
Lua compiles to a simple bytecode. It makes sure gotos are valid during this compilation.

It jumps directly to the label, and can't skip forward over the declarations of variables that are in scope at the label.

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?)