On 2010-08-20, at 9:31 , Maxime Chevalier-Boisvert wrote:
I spent a few hours last night experimenting with the arguments object in v8, and trying to come up with some modifications in the IR code generation to emulate v8's behavior, but it seems not to be the right approach to this problem. I've discovered that the association between the arguments object and the formal parameter names is somewhat tricky to implement. Namely, you can pass the arguments object to sub-functions, and modifications to it will be reflected in the formal parameters, but you can also modify formal parameter values in closures, and this will modify the arguments object.
It seems like the proper way to implement this would be through a code transformation. The arguments object should be assigned to a fresh temporary, and references to formal parameters should be transformed into references to indices in that object, even in nested functions. As an example:
[...]
This seems like the right approach to me, although I don't have Marc's extensive expertise on the subject.
Seeing Marc is busy, I will try to implement this myself. I need to be able to generate a "fresh" name that can't be accessed by the user (even through eval) for the arguments object alias. For this, I was thinking of prefixing the name with an illegal JS token, such as # or @.
That's a pretty common approach, we could have some prefix for all generated vars (e.g. tachyon#). I assume that you want to transform the code prior to building the IR, otherwise you could just reuse the same mechanism that is generates temporary var names in your IR construction phase.
Bruno