Re: [Jscheme-devel] Patch to allow multiple independent JScheme instances

[Timothy J. H. <tim...@ma...>]

On May 10, 2004, at 6:35 PM, Toby Allsopp wrote:

> Responses inline...
>
> On Mon, May 10, 2004 at 04:44:34PM -0400, Ken Anderson wrote:
>> 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.
So the stacks are needed because the implementation relies on 
threadlocal variables
and you need to reset the values of the threadlocal variables when the 
evaluator is complete?

>
>> 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 haven't looked at Toby's code yet, but I wonder if we can get by 
without threadlocal
variables? Perhaps a major revision (of Scheme.java, Primitives.java, 
....)
would eliminate the need for this complication (and the stacks of 
interpreters....)

>
> I agree with this.  My changes were meant to be the minimum to get this
> to work.
Yes, and its a great start!!

>  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.