This is a source of byte code bloat, and any constructor with 9 arguments,as is currently the case for some ScriptFunctions, is probably a bad idea.

Only the scope of a script function is dynamic, so much of the information passed to the ScriptFunction constructor could be passed in a static ScriptFunctionData object, created at code gen time and fetched from the constants table.

Notes:
1. MethodHandles are not so easy to pick up at code gen time. May have to remain separate args to the ScriptFunction constructor.
2. Possibly the ScriptFunctionData should just be hung from the ScriptFunction and shared by all instances of the function.