Helper functions from previous API call outputs in next call too

[Simon 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.

[Simon Lydell]

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

[Simon Lydell]

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

[Simon Lydell]

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

[Michael Ficarra]

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.

[Simon Lydell]

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

[Michael Ficarra]

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.

[Simon Lydell]

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

[Simon Lydell]

Just found efaa09b:

next up, remove {h,enabledH}elpers statefulness