It's really inconvenient, but possible, because most evals have access to global variables (and some even to local scope variables).
In the languages I am familiar with, they had the *same* scope as if the expression itself was there in the code where the Eval function was. It is just like a code replacment. I suppose I should have stated that assumption, but I have yet to see it otherwise.
And then you throw up in disgust at this slow unvieldy buggy contraption and choose a language that supports real anonymous functions.
Buggy? You have not identified any specific bugs. True, you get no compile-time checking, but if we are generating stuff during run-time, we don't have that anyhow. Slow? Perhaps. But I don't use it for finite element simulations or the like.
You seem to be agreeing with me that Eval is "good enough" for occassional usage, which is my point. If code was littered with eval's or dynamic execute's, then one might find closures would clean up the scoping issues more.
And no, I *don't* remember multiple regression. That was many many moons ago. My brain does a pretty good job of house-cleaning, except that it never asks permission before tossing. Kinda like my wife. Maybe if I studied your code long enuf I might figure it out, but I have other more practical things I would rather study if I go into study mode.