>
that would amount to shelling out,
If you realized it today, yes.
You could implement it as internal feature.
Nobody does, because the benefits of eval wouldn't justify the costs of a much larger binary.
| [reply] |
My point of view is from the flexibility and power offered by the eval feature: how much does it add to the power of the language. I agree, there are other costs (including Security). But I am focusing on the power offered. My thinking there is: in the future we will all be friends and the aim will be to max out the power of computing and not to protect from script-kids. If we don't manage that (i.e. all friends) we will waste 99% of resources in security and anything else will be second. Fastest way back to the Cave.
Eval is a very strong feature. It's a qualitative factor weighting for the interpreted languages which I, C being my alma-mater, thought are inferior and sloppy and just glue. I stress again my previous point: eval can share and modify "parent" program's state. Although I know eval for many years, pondering about its internals happened to me only lately while I am attempting an android app. Typical "taking for granted". In android universe, there are "activities", screens of the same app basically, which have no way by default to share state with other activities, part of the same App. You have to resort to serialising objects back-and-forth manually and with stupidly lame putString(), putBoolean() methods (I am at the beginning still, so I may find something more productive). But AFAIK primitive and insane.
With eval, a script can run all the scripts in the world and pass state to them forming a huge single-memory-space super-program. Sure you can shell out and pass state via command-line params or serialise it into files. Restrictions though apply. But with eval you can extend your program on-the-fly, as already pointed out, but with preserving its state still! Code improvement with Genetic Programming and eval for example. Although, again AFAIK (which is not much), is not happening with a (edit: compiled) program which already is running and tries to improve itself by modifying parts of it, as it runs. Sure, in a compiled language you can emulate eval by dumping state to disk, appending eval code to the original source code, recompile, run, load state from disk. With a HUGE caveat: hope that new executable and past state are compatible.
Nope, the future is interpreted.
bw, bliako
| [reply]
[d/l] |
| [reply] |
