[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, 09 Aug 2011 15:30:07 -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 alaric):

 I'd be interested to know more about the implications of this change.

 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`?

 As for first-class environments - I don't see them as so important, as
 IMHO the useful cases of programmatically building up an environment
 starting from a base that provides extra functions for use by `eval`-ed
 code can be done by doing so in an alist, then converting said alist to a
 big `let` that is wrapped around the code to `eval`, as long as objects
 like procedures are allowed as self-evaluating literals!

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]