Skip to content

Provide environment isolation for evals #4

Open
Brandon opened this issue Nov 30, 2018 · 1 comment
Open

Provide environment isolation for evals #4

Brandon opened this issue Nov 30, 2018 · 1 comment

Comments

@Brandon
Copy link
Owner

Brandon commented Nov 30, 2018

We currently load student source files and the reference source file into the same interaction-environment. This is terrible. It loads two files that should be isolated into the same namespace. Student source files have access to the testing functions (such as REF-bool-equal?) and answer/reference functions (through delay).

We currently solve the second issue with testOutputTransform, but there should be a better solution using environment manipulation to separate namespaces.

From some searching online, it looks like:

  • We can use (scheme-report-environment 5) to get a new namespace with only R5RS definitions inside of it. (It does not inherit definitions defined in the current scope.)
  • The second argument of eval allows us to run code within a specified namespace.
  • Unfortunately the plt-r5rs implementation of load doesn't contain a second argument to load a file into a specific namespace. But we can workaround this by composingeval and load.
    (eval '(load "referenceSolution.scm") (scheme-report-environment 5))
    
    This only gets us halfway though. Since the load portion is ran within a new environment, the definitions properly get defined in that restricted namespace. But since the filename is in the current scope, that load expression no longer has access to the variable containing the filename. So one of the challenges here is retaining dynamic file loading. Perhaps there's a way to copy a definition into this new namespace, but I haven't found it yet.
@Brandon
Copy link
Owner Author

Brandon commented Nov 30, 2018

Also helpful: https://github.com/racket/r5rs/blob/master/r5rs-lib/r5rs/main.rkt

This file contains all the definitions in the PLT R5RS implementation.

Sign in to join this conversation on GitHub.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant