The whole issue started as a thought exercise and I exchanged some emails with WitchLord on the matter of how to provide features to allow stand-alone compilation of AS code that is using registered entities from the host application. In my last post to another thread it just dawned to me that using the "import" statement in a script allows the compiler to refer to functions that are not yet bound to the module. Thus, registered global functions could be mimicked with a set of import statements. These statements could in turn be held in a separate script file that is prepended as a script section to the main source(s) and acts as a sort of configuration file for the compiler. I don't know (haven't checked) if this can be extended to other types of elements. Presumably, global variables could be mimicked too, although I assume that it is not yet possible to import custom types from another module. Fleshing out with an example: -- Compiler_Config.as ------------------------ import void MyHostFunc1() from "DummyModule"; import void MyHostFunc2() from "DummyModule"; : : ---------------------------------------------- -- MyScript.as ------------------------------- { void DoSomething() { MyHostFunc1(); MyHostFunc2(); } ---------------------------------------------- Let's say the compiler is required to compule script "MyScript.As" to module "MyModule". The compiler adds the "Compiler_Config.as" script as the first script section to "MyModule", then it adds "MyScript.as" to the module. The compiler should then be able to compile "MyModule" without complaining. [edit] It's very unlikely that the resulting module can be used directly because unresolved references to imported elements are likely to be different from references to registered host elements. Still, this functionality may prove useful as a means of ensuring that a script compiles cleanly. [/edit]