6 ms·
The root of all eval
- shakna 10y agoPerl6 has blocks, so eval already implicitly receives an environment from within which to evaluate. Why jump up and down screaming eval is super bad, when instead you could have allowed users to specify the context of eval, and made it safe to use?
- hyperpape 10y agoIs it really going to be safe to use? I don't know Perl that well, but it feels like there's enough language features to make a safe eval harder than writing your own parser for a DSL. That's certainly the case for Python: https://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html https://nedbatchelder.com/blog/201206/eval_really_is_dangero...
- shakna 10y agoPython's eval is crippled, it can't take a full environment. Suppose for a moment that the scope of eval was truly an environment: And you don't supply the resulting environment with anything but the functions you want. Not even the dot operator, let alone magic builtins. Python's eval suddenly becomes much safer. Unfortunately such an eval is harder to implement in Python, because every object carries it's magic methods with it, rather than looking them up elsewhere.
- hyperpape 10y agoInteresting. Is there any language you or the sibling have used that does this with eval, and does it find much use?
- BuuQu9hu 10y agoE and Monte have safe eval() as a consequence of being object-based capability-safe languages; there's no way to cause any effect outside eval() worse than an infinite loop. To the second part of your question: as you have undoubtedly noticed, you've never heard of E nor Monte.
- hyperpape 10y agoFunny that you say that. When I sat down at my machine at work, one of the 100 or so chrome tabs I had open was a page about The Vat: http://www.erights.org/elib/concurrency/vat.html http://www.erights.org/elib/concurrency/vat.html.
- BuuQu9hu 10y agoWe have vat documentation too: http://monte.readthedocs.io/en/latest/vats.html http://monte.readthedocs.io/en/latest/vats.html
- shakna 10y agoSure! Most of the time, it just makes it easier to parse and interpret input in a safe manner. * Racket [0], sometimes used when you don't want to use Racket's way of designing DSLs, or if you want to interface to databases simpler. * Scheme [1], used when designing DSLs, interacting with databases. You often see it go hand-in-hand with X-Expressions. * Lua [2] can, but it is rarely used. Note, the link for Lua actually lists a whole host of languages where this can be technically done, but not all are entirely safe. I think it's uncommonality is not because of it's inconvenience or rarity, but rather the mantra of 'eval is evil' in the programming community, even when it doesn't apply. [0] https://docs.racket-lang.org/guide/eval.html https://docs.racket-lang.org/guide/eval.html [1] https://www.gnu.org/software/guile/manual/html_node/Environments.html https://www.gnu.org/software/guile/manual/html_node/Environm... [2] https://rosettacode.org/wiki/Runtime_evaluation/In_an_environment#Lua https://rosettacode.org/wiki/Runtime_evaluation/In_an_enviro...
- abecedarius 10y agoPython wasn't designed from the start with this kind of security concern in mind. It could have been, like http://erights.org/ http://erights.org/. In such languages it's reasonable to say "you can write a user-level drop-in replacement for eval(), and therefore we can make the built-in eval accessible to all code without any extra security-design concerns" (though of course you still need care in implementation).
- SwellJoe 10y agoA block isn't a sandbox, and the base language itself has everything one needs to shoot gaping holes in feet. I'm not sure how handing off an empty (or whatever) environment to the eval'ed code can be "safe". I agree with the author that this is probably overkill, in terms of warning about eval, but I'm also not understanding how merely having a block with a block scoped environment can make eval safe.
- shakna 10y agoAn empty environment handed to eval would always result in an error, as eval would have no access to syntax or inbuilts or anything else. Having blocks simply means half the work of implementing eval this way has already been done in the interpreter. Eval wouldn't have access to the base language if handed an empty environment.
- SwellJoe 10y agoMaybe I don't understand the meaning of "blocks" in Perl 6 (if they work this way, I definitely don't understand them). I've never worked in Perl 6, except a couple of tutorials, so that's entirely possible. I mean, I know Perl 6 has the ability to fundamentally change the language within the language itself.
- shakna 10y agoThe only thing blocks have to do with this, is that Perl6 has to internally track state so that closed over values go out of scope when their parent block ends. End of story. Maybe I can try explaining again. Eval is unsafe as it reads input values in terms of the current state of a program. It's environment is implicitly given, and includes the entirety of the Perl6 language, as well as anything user-created. But, what if the programmer was allowed to supply that context? Rather than a blacklist against certain bad things, this is a whitelist where you supply every single thing that eval is allowed to use. Other languages already have this. Scheme example that works: (eval '(+ 1 2) (let (null-environment) '(+ . +))) Scheme eval that fails: (eval '(+ 1 2) (null-environment)) Perl6's flexibility is less unsafe when you don't provide anything flexible.
- malft 10y ago"It's just a normal function." No, it has magical access to the lexical scope.
- kazinator 10y agoIf eval appears to have same access if defined like in the article: my &eval = &EVAL then that is largely moot.
- hyperpape 10y agoIts possible that's a bug and not an intentional design decision. I certainly hope it is, because I agree with you that it doesn't make sense to hide it behind a pragma but have this workaround.
- adrianm 10y agoIsn't eval required to run in the null lexical environment? Or is that only true in Lisp?
- simcop2387 10y agoNo, in perl eval explicitly has access to the local scope. This is used for capturing otherwise fatal errors in perl (it can be used similarly to try/catch).
- kazinator 10y agoWouldn't the handlers for exception handling by dynamically scoped, not lexically? If we have a try block, and call a function, and if that function throws, we want the try block to be able to catch that. The function is not understood as having magic access to an environment; it's a pervasive dynamic environment that is visible to the current execution context at all times, in which exit points for non-local transfers are established. That's almost the entire point since an error situation that is entirely confined to a lexical scope can be dealt with using some local control flow (some form of goto, or structured derivative thereof).
- jes5199 10y agoexpecting perl not to use silly names for things is like expecting clowns not to wear big shoes
- ch_sm 10y agoI lol'd.
- mijoharas 10y agoMy biggest question about this is did the guy not understand why the flag was called `MONKEY-SEE-NO-EVAL`? Because that name was my favourite part of the article...
- petre 10y agoYes it's cool but maybe not everybody gets the drift. That and the fact that Perl6 error messages are really meaningful as in not a wordplay on a reference to sanzaru.
- mijoharas 10y agoJust learned that the 3 wise monkeys are called Sanzaru. Thanks!
- kmill 10y agoThe article is called "The root of all eval." I think the author gets it.
- jwilk 10y agoTo me it looks like the author is oblivious of the pun in MOKNEY-SEE-NO-EVAL, even though he made the same pun in the title.
- labster 10y agoI don't think it's possible to be a Perl 6 core developer and not get basic puns like this. #perl6 is nothing if not a series of puns mixed with code.
- tragic 10y agoHis point is merely that either this is a seriously bad idea that you should never do, in which case you should not attempt to communicate it through a silly pun, or it is acceptable, in which case it shouldn't be hidden behind a compiler pragma.
- 10y ago
- keeperofdakeys 10y agoIt's worth noting that eval in perl5 can be used with a codeblock to give basic exception handling, in perl6 this functionality has been moved to try. So while it's quite common to use eval in perl5, I'd expect much less usage in perl6. The name change is probably a good reminder of this.
- BuuQu9hu 10y agoIndeed, eval() is a safe tool if (and only if, I suspect) there is no additional authority granted by eval(). This suggests that a metacircular interpreter would be the main core of such a safe eval().
- tshadwell 10y agoSo in order to use a function that exposes the software to serious undue security risk unless used correctly, the engineer is pushed to do research? That really doesn't seem like a bad thing...