From: Toby A. <tob...@pe...> - 2004-05-10 22:35:36
|
Responses inline... On Mon, May 10, 2004 at 04:44:34PM -0400, Ken Anderson wrote: > Yes, its fine to include the developers. There ideas can certainly > help figure out how to proceed. > > Here's the tests you added: > "05/05/2004" ;; multiple independent environments > ;; I use true here to mean run during the test for side effects > (let ((x 0) > (js1 (JS.)) > (js2 (JS.))) > (true (begin > (set! x 0) > (.load js1 "(define x 1)") > (.load js2 "(define x 2)") > (display x)(newline))) Oops, I meant to remove that display. > (= x 0) > (= (.eval js1 'x) 1) > (= (.eval js2 'x) 2) > (true (set! x 10)) > (= x 10) > (= (.eval js1 'x) 1) > (= (.eval js2 'x) 2) > (true (.eval js1 '(set! x 11))) > (= x 10) > (= (.eval js1 'x) 11) > (= (.eval js2 'x) 2) > (true (.eval js2 '(set! x 12))) > (= x 10) > (= (.eval js1 'x) 11) > (= (.eval js2 'x) 12)) > > js1 and js2 are two independent Schemes along with the one that's > evaluating this code. Since they are independent, it doesn't feel > like there's a need to push and pop evaluators. What am i missing? When this thread's current evaluator is set to that of js1, the previous current evaluator (the one that's evaluating the test) needs to be saved somewhere so that it can be restored. Perhaps the need would be clearer in the case of: (= (+ (.eval js1 '(+ (let ((js3 (JS.))) (.load js3 "(define x 3)") (.eval js3 'x)) x)) x) 24) In this example, the variable called 'x is looked up in three different, nested evaluators. As each .eval finishes, the current evaluator must be restored to what it was when the .eval was called. > Perhaps there are static methods in Scheme.java and other classes that > should simply be removed. For example, Scheme.runJscheme() should no > longer be static, so the currentEvaluator() call in that method > wouldn't be necessary. runJscheme() would have to be moved to > Evaluator, i guess. I think getting rid of the Scheme class might be > the way to go. I agree with this. My changes were meant to be the minimum to get this to work. Once the semantics are agreed upon then the refactoring can begin in earnest :-) > One thing we need to do is tweeze apart is construction of an Evaluator. > It should probably take an environment as an argument. Of course, you > may want to fill that environment with the right stuff, such as > Primitives, which takes an evaluator. In fact, i see that Primitives > and U are probably the first issues to get right. Yes, breaking apart the concepts of "environment" (i.e. variable bindings) and "evaluator" (e.g. call stack, optimization settings, verbosity) is something that I considered. You can see in my comments that I was a bit undecided about whether I was talking about environments or evaluators. > I think i understand what you did to take another wack at it, > hopefully with help from Tim. I'm very interested to see what you make of it. > k > > PS. Do you sail? Ironically enough, no, but I have been involved in some sailing-related research. Toby. |