kend@data.UUCP (Ken Dickey) (03/07/91)
hayes@jazz.concert.net (Brian Hayes - Sigma Xi) writes: >In Article 268 in comp.lang.scheme Marc Feeley >(feeley@chaos.cs.brandeis.edu) writes: >> However, it is not possible to write a portable EVAL procedure because there >> is no way in standard Scheme (R4RS or IEEE) to access global variables >> through their names. We would like the following code to print 100: >> (define x 50) >> (EVAL '(set! x (+ x x))) >> (write x) >> EVAL would be possible given procedures to reference and set global variables ... >Doesn't this line of reasoning lead to the conclusion that EVAL is >inextricably part of the interpreter, rather than something we can >add on to an existing interpreter? EVAL has to know how environments >are represented internally... ... >Brian Hayes >hayes@concert.net You guys are going to have to help me see the problem. Why is it not possible to write a repl which captures "top-level" values and implements its own EVAL and manages its own environment representation (i.e. by redefining set!, load, etc.)? It could certainly do the transformation for code to be compiled by changing (...x...) to (...(get-value x my-env)...), etc. and calling the standard compiler {if any}. The major constraint is that the new world has to exist before new code can be added (as pre-existing code would have the old bindings). Such a scheme (ugh!) would probably be less efficient, but would certainly be portable. -Ken Dickey