使用Node运行GHCJS程序的变量太多

Question

I'm trying to run a program built with GHCJS using node.js. However, I get the following error:

SyntaxError: Too many variables declared (only 131071 allowed)
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:906:3

1. Is it possible to increase the number of allowed variables in node?
2. Is there a better utility for running JS files which would allow for more variables
3. Are there optimization tools which could automatically reduce the number of variables?

Note that this is machine generated JS, so I have no desire to go through by hand and reduce the number of variables.

Any ideas are welcome.

Answer 1

Must be a pretty big program :)

I have run into the variables limit on very old node versions (32k) but not yet into the new raised limit. The problem is similar to the Windows DLL symbols limit causing problems with dynamic linking, and possibly just as annoying.

GHCJS emits all generated code as top-level functions and variables for efficiency and simplicity (closures are handled by the STG implementation, so nested functions are not necessary here).

The limit only applies to local (function) scopes. Unfortunately, node.js uses a module system, and loads all code implicitly into a local scope.

Fortunately JavaScript gives us a way to still declare global names from a local scope, you just need to remove the var keyword! I think you should be able to run the script if you replace all var h$ at the beginning of a line with h$ .

Alternatively you can try running the script with the SpiderMonkey JS shell or in a browser, but these give you a more limited environment (no filesystem access, cannot start or interact with other processes).

If the variable limit remains a problem for you, please open a ticket at https://github.com/ghcjs/ghcjs/issues so we can try to find a more permanent solution (probably by adjusting the link-time transformation step to divide the generated code into multiple modules).