Helper functions from previous API call outputs in next call too

[lydell]

$ node -pe "var cs = require('./lib/module'); cs.cs2js('a=c in d') + '\n--------------\n' + cs.cs2js('a=1')"
// Generated by CoffeeScript 2.0.0-beta9-dev
void function () {
  var a;
  a = in$(c, d);
  function in$(member, list) {
    for (var i = 0, length = list.length; i < length; ++i)
      if (i in list && list[i] === member)
        return true;
    return false;
  }
}.call(this);
--------------
// Generated by CoffeeScript 2.0.0-beta9-dev
void function () {
  var a;
  a = 1;
  function in$(member, list) {
    for (var i = 0, length = list.length; i < length; ++i)
      if (i in list && list[i] === member)
        return true;
    return false;
  }
}.call(this);

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[lydell]

I think this happen because enableHelpers is a module-global variable. It should be created on each invocation.

[lydell]

Are there any API tests? In case I end up making a PR…

[lydell]

Does it make sense to pass helpers to each rule, just like inScope, ancestry etc.?

[michaelficarra]

I don't think so. helpers is something that needs to be mutated (or threaded through return values monadically), right? inScope and ancestry are entirely informational. They are built up in the traversal. Rules do not mutate them or pass out new values for them.

[lydell]

Then I don't know how to fix this issue :(

[michaelficarra]

Yeah, it's a shitty one. You can keep the state in the Compiler instance and mutate it there instead of threading it through the compilation rules. It's cleaner. Unfortunately, JavaScript/CoffeeScript do not allow for very powerful abstraction.

[lydell]

I thought about keeping the state on the Compiler instance as well, but the rules don't seem to have access to it?

[lydell]

Just found efaa09b:

next up, remove {h,enabledH}elpers statefulness