Re: [Jscheme-user] Multiple independent interpreters

[Ken A. <kan...@bb...>]

I think we need to do this carefully.  I'd like to hear what Tim has to say.

Peter Norvig's original intent was to make jsint.Scheme static "to keep it simple", basically.  However, it does cause problems with things like Scheme.out$ So for example if you have multiple using.Active.interactor() windows up only the last one has control of input and output.

In fact, i think its fair to say that Peter's design choices were influenced by Java's capabilities at that time, for example , "keep the number of classes small" to minimize applet load times ... With hotspot, we might now make other choices.

We could also run JScheme in JDK 1.02 environments, which i think we have finally gone beyond.

A third alternative to your proposals might be to make certain things thread local, though i haven't thought about this.

Tim came up with the jscheme package in an attempt, i think to clean the original code a little, by using Interfaces for example, and he has an example of a mini JScheme where most of the primitives are written in Scheme.  So, we need to consider carefully where your proposed class goes.

Please don't use the name Interpreter.  JScheme is not interpreted.  JScheme code is read, then compiled and then executed.  The compiler is both simple and effective (see how those two words almost cancel each other out).  Many people avoid Lisp languages because they fear they are interpreted.  Also JScheme code can be compiled to Java with Tim's compiler.  Evaluator might be a better class name.

In fact, maybe this is a time for refactoring.  I've been thinking that jsint.Scheme should be broken up.

At 09:34 AM 3/10/2004 +1300, Toby Allsopp wrote:
>I'm wanting to use JScheme as a way to script a J2EE application.  I
>want to be able to run a scheme program that can send a closure to the
>J2EE application and have it executed by an EJB.  The serialization
>support I submitted is one part of this.
>
>The next big hurdle is that I don't want the results of executing a
>closure in the EJB to taint future executions, and I want to support
>multiple threads executing independently.
>
>Because everything is static, the only way that I can see to have
>independent interpreters is to play games with class loaders, i.e. to
>create a new class loader to load the JScheme classes for each
>interpreter instance.  This approach is unsatisfactory to me because I
>intend to run in a J2EE environment and messing with class loaders is
>explicitly forbidden by the specification.  The performance impact of
>creating a class loader and loading the classes also troubles me.
>
>I propose to make all per-interpreter state (e.g. the dynamic
>environments, input/output ports) non-static and introduce a per-thread
>"current interpreter".  I see two alternative implementation strategies:
>
>1) Introduce a new class, jsint.Interpreter, that is essentially a
>de-static-ed version of jsint.Scheme.  Then, replace the contents of
>each static method in jsint.Scheme with delegation to the corresponding
>method of the current jsint.Interpreter instance.
>
>2) De-static-ify jsint.Scheme and change every static call to
>Scheme.<something> to Scheme.currentInterpreter().<something>.
>
>My questions are:
>
>Does anyone see a better or easier way to achieve what I want?
>
>Which of the two proposed options would be preferred?
>
>Toby.
>
>P.S. Yes, I am volunteering to make these changes.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>Jscheme-user mailing list
>Jsc...@li...
>https://lists.sourceforge.net/lists/listinfo/jscheme-user