[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-janitors] #643: CR: overhaul environment representation in

From: Chicken Trac
Subject: Re: [Chicken-janitors] #643: CR: overhaul environment representation in the evaluator
Date: Tue, 16 Aug 2011 09:35:20 -0000

#643: CR: overhaul environment representation in the evaluator
  Reporter:  felix           |       Owner:  felix            
      Type:  change request  |      Status:  new              
  Priority:  minor           |   Milestone:                   
 Component:  core libraries  |     Version:  4.7.x            
Resolution:                  |    Keywords:  eval environments

Comment(by felix):

 Replying to [comment:3 alaric]:
 > In particular, my favourite drum to beat is sandboxing: what will this
 mean for `eval`-ing untrusted code, if the global environment is exposed
 by `interaction-environment`, and the other environments have `new
 toplevel definitions are not possible`? Will we be able to make an
 extendible but existing-bindings-immutable (or existing-bindings-locally-
 mutable) clone of `scheme-report-environment N`?

 That's correct: it will not be possible to extend the toplevel environment
 for `scheme-report-environment` and `null-environment` (note that this is
 what R5RS specifies). Creating an extensible environment will not be
 possible directly, but since I see the need for some sort of sansdbox as
 well, I thought about providing a different facility (a small framework
 for extending the interpreter) separate from the core system, but with the
 core system providing the necessary hooks.

Ticket URL: <>
Chicken Scheme <>
Chicken Scheme is a compiler for the Scheme programming language.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]