Scopes: Bindings for nested scopes.

[rakudrama]

How are ranges and scopes meant to be used for bindings in nested scopes?

Consider stepping through the following (Dart) code. Bindings come into scope one at a time.

// scope 1: file scope: {play}
void play(int seed) {          // scope2: parameters: {seed}
  int counter = seed;          // scope3: declaration: {counter}
  int inc(int n) {             // scope4: declaration of `inc`: {inc}
                               // scope5: parameters: {n}
    return counter += n;   // in scope: {n}; parent: {inc}; parent^2: { counter}; parent^3: {seed}
  }
  inc(2);
  inc(-2);
  if (counter != seed) throw "bad";
  register(inc);
}

Local functions are represented as objects with a call method. Variables shared between functions are located in a 'context' object.
The generated code would follow this pattern:

function play(s) {
  var  ctx = {c: s};
  var i = new play_inc(ctx);
  i.call$1(2);
  i.call$1(-2);
  if (ctx.c != s) throw "bad";
  register(i);
}

function play_inc(ctx) {
  this.ctx = ctx;
}
play_inc.prototype = {
  type: "int(int)",
  call$1(a) {
    // Bindings available:
    //   "n": "a"
    //   "inc": "this"    // available, even though not used in 'inc'. This could be `null`.
    //   "counter": "this.ctx.c"
    //   "seed": null     // not available because it is not used in `inc`
    return this.ctx.c += a;
  }
}

The spec says:

9.3.2 Generated Range Record
...
[[Bindings]] are intended for debuggers to retrieve the values of original variables. The length of [[Bindings]] must be equal to [[Variables]] of the corresponding Original Scope Record. Given an index i, [[Bindings]][i] describes how to retrieve the value for the original variable [[Variables]][i].

The equality constraint implies that each scope needs to be referenced by a separate Generated Range Record.
Is this the intention?

It seems a bit wasteful to require an extra three 'administrative' generated ranges.

[szuend]

Not sure I follow 100%. I would have expected the following scope structure:

• Function scope play. Variables: ['seed', 'counter', inc']
  • Function scope inc. Variables: ['n']

Ranges:

• Range for play (the JS function "play"), referencing the play scope. Bindings: ['s', 'ctx.c', 'i.call$1']
• Range for play_inc with no definition scope
• Range for call$1, referencing the inc scope. Bindings: ['a']

If the compiler can re-materialize the variables of play while inside call$1, it can optionally emit a:

• Range for call$1, referencing the play scope. Bindings: [null, 'this.ctx.c', 'this']

This range would be the parent of the other rangecall$1. But this is not strictly necessary. The debugger would mark the outer scope's variables seed and counter as unavailable while paused in inc, since it doesn't find any generated range for the play scope in the range chain.

Re the original scopes of the example: Not sure why scope 3 and scope 4 are different? Are they different lexical scopes in Dart? I'd also expect a generator to omit the additional block scope for functions if the parameters don't have default expressions.