Allowing other functions to modify local variables inside of callers is a bad idea. It makes optimization much more difficult, and renders code much less intuitive. I think that the property that functions are "black boxes" that provide an interface to the outside is very important for proper decoupling of functionality. Having functions you can call that can do *anything* to the caller's stack frame is not good, and is not as useful of an extension mechanism as you might think.
- Maxime
The example given in the previous mail where a bunch of constants are declared in a function scope has brought an idea to ease declarations of such constants when there is an important number of them. It would bring module-like capabilities, decoupling the internal layout of modules from the usage made by clients of that module.
If the function context could be accessed as a variable in a similar way that the global object can be accessed in the global scope through "this", we could simply write a function that installs all those declarations on the context object. Here is an example:
function foo () { var context = foo.getContext(); x86.import(context); // or it could be context.import(x86)
// Some cleaner code here var mem_access = _(ESP);}
x86.import = function (context, /* optional */ import_list) { if(import_list) { for (var i in import_list) { context[i] = x86[i]; } } else { context["_"] = x86._; context["ESP"] = x86.register.ESP; //... }
}
Given that we will have access to the internals of the compiler, I think it would be a reasonable extension, after the bootstrap is done. It would however prevent us from bootstrapping on a stock javascript engine. We might find a workaround using eval but that would violate our "no-eval" policy.
Erick _______________________________________________ Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list