Implementing eval()

Jan 28, 2010 at 3:40 PM
Edited Jan 28, 2010 at 3:41 PM

My language has recently turned into something useful, and I've only really had one big issue that I have sort of ignored - eval(), and the way it's supposed to work in JavaScript (works the same in Python to the best of my knowledge). Eval is supposed to have access to the entire enclosing scope, but dynamically during runtime.

The implementation for normal method calls, etc. work sort of the way that dino outlined in this http://dlr.codeplex.com/Thread/View.aspx?ThreadId=80047, when a variable needs to be closed over a special closure cell is created that wraps up all variables that needs to be closures for a specific function, since I have no idea of knowing how what variables will be accessed inside the eval() call I figured I would have to create a closure cell for every variable available in the scope of all functions that are calls that calls the identifier 'eval'. Something like this:

closure = CreateClosureCellOfEverythingInScope();
eval(arg0, arg1, [, argN ], closure);

And create a full closure environment even if the function name just happens to be eval (the user could create a function named eval in the current scope, which isn't the real eval function, etc.). As usual I tried to read the IronPython sources but got lost halfway through it due to the immense size.

Coordinator
Feb 2, 2010 at 5:23 PM

What you describe (create a closure environment if anything named eval is called) is exactly what IronPython does.  Over in IronPython’s CallExpression there’s a function called NeedsLocalsDictionary which sees if the call is to one of several different functions which would need for us to lift all the variables into the heap.  When we perform name binding we walk the entire tree and check all call expressions to see if we’ll need to do this.  If we do then we mark the current function as needing a locals dictionary and then lift all the variables.

The downside of this is that if eval is aliased of course we won’t provide access to the variables but everyone in the Python community seems to agree that aliasing eval is a silly thing to do.

From: fholm [mailto:notifications@codeplex.com]
Sent: Thursday, January 28, 2010 8:41 AM
To: Dino Viehland
Subject: Implementing eval() [dlr:82313]

From: fholm

My language has recently turned into something useful, and I've only really had one big issue that I have sort of ignored - eval(), and the way it's supposed to work in JavaScript (works the same in Python to the best of my knowledge). Eval is supposed to have access to the entire enclosing scope, but dynamically during runtime.

The implementation for normal method calls, etc. work sort of the way that dino outlined in this http://dlr.codeplex.com/Thread/View.aspx?ThreadId=80047, when a variable needs to be closed over a special closure cell is created that wraps up all variables that needs to be closures for a specific function, since I have no idea of knowing how what variables will be accessed inside the eval() call I figured I would have to create a closure cell for every variable available in the scope of all functions that are calls that calls the identifier 'eval'. Something like this:

closure = CreateClosureCellOfEverythingInScope();
eval(arg0, arg1, [, argN ], closure);

And create a full closure environment even if the function name just happens to be eval (the user could create a function named eval in the current scope, which isn't the real eval function, etc.). As usual I tried to read the IronPython sources but got lost halfway through it due to the immense size.

Read the full discussion online.

To add a post to this discussion, reply to this email (dlr@discussions.codeplex.com)

To start a new discussion for this project, email dlr@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com