Re: [Jscheme-user] Multiple independent interpreters

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

Hi Toby,
   Thanks for the serialization/deserialization extension.
Its a nice feature to have and I look forward to seeing what
we can do with it!

As for running multiple independent Scheme's, I think it is
a good idea as long as it doesn't make the code too complex
(after refactoring...)

On Tuesday, March 9, 2004, at 08:46 PM, Toby Allsopp wrote:
> On Tue, Mar 09, 2004 at 06:58:35PM -0500, Ken Anderson wrote:
>> I think we need to do this carefully.  I'd like to hear what Tim has
>> to say.
>
> I completely understand.  I'm proposing a fairly major change.
It would be nice to be able to create new JScheme instances that
could run independently of each other. I would support an effort
to do this, provided it doesn't make the implementation too complex
and unwieldly (which is unlikely).
>
>> 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.
It might make modules easier to implement as well as we could
create a new Scheme instance to load the module into and then
copy its exported bindings into the current Scheme instance, so
it could actually simplify the code somewhat.
>>
>> 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.
>
> I haven't considered applet loading performance as I'm not interested
> in using JScheme in an applet.  I don't think anything I've done will
> cause problems in that department.
>
>> We could also run JScheme in JDK 1.02 environments, which i think we
>> have finally gone beyond.
>
> In my initial implementation (which I'm testing right now), I've used
> some JDK 1.2 classes (and possibly some 1.3 ones), but that can 
> probably
> be worked around if earlier JDK compatibility is required.
>
>> A third alternative to your proposals might be to make certain things
>> thread local, though i haven't thought about this.
>
> I don't think there's any choice but to make some things thread local 
> if
> you want to avoid passing the execution context (perhaps that's a 
> better
> name than interpreter) into every method.
If we make all "execution context variables" thread local, then 
starting a new thread
will be less lightweight. One nice use of threads is to write a simple 
server that starts
a new thread for each incoming socket and then reads from the socket 
and writes to
a common queue (with synchronization as appropriate), I wouldn't want 
this pattern
to be broken. Its true that the nio package makes this use of threads 
unnecessary, but
for small servers it is a nice use of threads....

So, I guess I'd be careful with ThreadLocal variables. Perhaps the 
default behavior
would be to have ThreadLocal variables be initialized to be equal to 
the parent
thread's values, but that resetting a Scheme instance would rebind the 
ThreadLocal
variables to initial values???

>
>> 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.
>
> I must say that I get confused trying to tell the difference between 
> the
> jsint and jscheme packages.  It kind of looks like jscheme is the
> interface and jsint is the implementation.
Thats essentially right. I wanted jscheme to be the public face of 
JScheme so that
we could change the jsint package radically and not break any programs 
that relied
only on the jscheme package.... With that philosophy, I would suggest 
leaving the
jscheme package mostly unchanged (except for some new functionality 
procedures in
jscheme.REPL) and making most of the patches to jsint.Scheme

>
>> 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.
>
> Hmm, I'll try to stay out of naming arguments, I always end up with a
> bad name.  I suppose I was misled by the comment at the top of
> Scheme.java :-)
We do need a better name as Interpreter has a bad connotation maybe
just callling it a Scheme instance would do (and we'll need to create a
Scheme constructor ....)

>
>> In fact, maybe this is a time for refactoring.  I've been thinking
>> that jsint.Scheme should be broken up.
>
> I think some refactoring would help to sort out what this new class
> should be called.  I don't feel close enough to the philosophy behind
> JScheme to do any really useful refactoring, so I'm going to prepare a
> patch that does the minimum I can to get it working and hope that it's
> of use.
Sounds good. We could refactor after you patch. I have some
fairly big JScheme programs that make use of modules, threads, and
other features that will provide a good test of whether the patch breaks
any older functionality.... We also have the unit tests, but they are 
not
yet comprehensive....

---Tim---

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