On Friday, 10 June 2016 at 17:36:02 UTC, jmh530 wrote:
Ah, it produces mixin("1+2") and evaluates that.
Sort of, 1 and 2 are both runtime variables there so it really
produces mixin("a+b") after setting a = 1 and b = 2 above.
But yeah, that's the idea - it just hoists that mixin to runtime
for scripting.
What's the PrototypeObject sc I see everywhere doing?
sc is short for "scope" - it refers to the chain of local
variables. So consider the following:
var a = 1;
function foo() {
var b = 4;
var c = a + b;
}
foo();
So as this is interpreted by my thing, it is like it runs the
following D code:
// this happens as part of the interpreter initialization
auto globalScope = new
PrototypeObject(globals_the_d_programmer_passed);
// now it starts running
auto currentScope = globalScope;
// var a = 1;
currentScope["a"] = 1; // it holds the local variables!
call_function("foo", []); // script foo();
// when we enter the new scope inside the function, it
// creates a new object, based on the old one
currentScope = new PrototypeObject(currentScope);
// var b = 4;
currentScope["b"] = 4; // remember the scope changed above, so
this is local to the function now
// var c = a + b;
currentScope["c"] = currentScope["a"] + currentScope["b"];
/*
OK, so at this point, we get two variables: a and b. That's
what the sc object in the script.d source represents - what
I called currentScope here.
The opIndex does two things: check the current scope for the
name. If it is there, return that value. If not, go up to
the parent scope and look there. Continue until you find it,
of if it isn't there, throw a "no such variable" exception.
It'd find b in the current scope and return the
function-local variable, and it'd find a in the parent scope.
*/
// and now that the function is over, we pop off the local
// variables from the function by setting the current back
// to the old parent
currentScope = currentScope.parent;
So yeah, the sc in the interpreter is just the currentScope from
the pseudocode, a chain of AAs holding the local variables.
