3 ms·

A 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

A 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 ago
An 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 ago
  Maybe 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 ago
    The 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.

shakna 10y ago

An 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 ago
Maybe 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 ago
  The 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.