Re: [Jscheme-user] Multiple independent interpreters

[Toby A. <tob...@pe...>]

On Mon, Mar 15, 2004 at 05:12:00PM -0500, Ken Anderson wrote:
> At 08:20 AM 3/15/2004 +1300, Toby Allsopp wrote:
> > The expected usage is that any Java code that wants to make calls to
> > JScheme needs to wrap them in:
> > 
> >  JS.enter();
> >  try {
> >      ...
> >  } finally {
> >      JS.exit();
> >  }
> 
> At first look, i don't like this.  I don't like having to do a
> try/finally in Java to get something done for me by Scheme.  My first
> suggestion of leaving the JS interface alone is probably wrong.  
> 
> The way JS is typically used is you define a Java class that loads
> some Scheme code as a static init and then defines some Java methods
> that do JS.call() to get the behavior done for it.  So putting a
> try/finally around one line is too costly.

Okay, this usage suggests that you probably want to create an instance
of JS and call non-static methods on it.

> You may also want to turn an s-expression as a string into an Object.
> Maybe, JS should just be a wrapper around an Evaluator and a class or
> a Thread that wanted Scheme evaluated would just set up the Scheme
> environment it want the Evaluator to have and call the appropriate JS
> functions.  

I'm not sure I follow what you mean there.  My interpretation is to
basically make all JS methods non-static and provide a constructor that
takes an evaluator as an argument (and one that doesn't).

> > I don't think ARGS is referred to outside of jsint.Scheme, so it
> > doesn't really make much difference either way.  I'd probably prefer
> > it to be an instance field in Evaluator so that you can run multiple
> > scripts that use the args and don't know about each other.
> 
> ARGS is there to allow Scheme code to see what arguments were passed
> in.
> Any piece of code might want that, but it certainly doesn't make much
> sense in a "container environment".  So maybe ARGS should just be a
> global variable in the initial environment so it can be used by any
> Evaluator down stream, was my initial thought.  However, Looking at
> all the arguments doesn't make much sense because the arguments are
> processed by Scheme in a particular way and you can use the -main
> option to take over interpreting the rest of the arguments, as in
> src/using/command.scm for example.  So, my proposal now is to get rid
> of ARGS.  In Common Lisp, proposals were named like this:
> get-rid-of-args.

It turns out that it doesn't bother me either way :-).  I'll probably
leave it with the easiest to implement semantics and let it be removed
or retained by someone who has an interest in it.

> > > What arguments should the constructor take?  Probably a
> > > DynamicEnvironment at least optionally, but probably also the
> > > input, output, and error.  Try to avoid setter methods, we want to
> > > think functionally when we can.
> > 
> > Do you intend the DynamicEnvironment argument to intialise
> > INTERACTION_ENVIRONMENT?
> 
> The idea was that evaluators could somehow share environments so
> either an evaluator could load specific code, as you might want in
> scheme-server-pages or  could share code that was only loaded once,
> which you might want if you're a server spawing a new evalutor for
> each thread, but they all have the same behavior.

Oh, I see.  I'd expect the threads to just share an evaluator.  There's
not much difference, but it does make more sense to just share the
environment if that's what you want.

> > A fair amount of existing code assigns to the input and output
> > fields.  Do you mean to replace that with code that instead creates
> > a new Evaluator?
> 
> No, this code must bechanged into nonstatic calls.

This is what I currently have, I think.  Once we have the try...finally
issue above sorted out I'll post the code and we can get into specifics.

> > > Also, i once made eval and load replaceable procedures, so for
> > > example you could get R5RS macros.  But that disappeared when Tim
> > > put in DynamicEnvironments.
> > 
> > Sounds cool :-)  I don't know what it means though :-(
> 
> (load) and (eval) are Scheme procedures that have fixed semantics
> written in Java.  By redefining them, you can change the semantics for
> example by adding a more powerful macro system than Scheme has by
> default.  Or you could play with new evaluation models as in Paul
> Graham's ARC language
> http://www.paulgraham.com/arc.html
> 
> so you could do things like
> 
> (define v #(0 1 2 3))
> (v 1) -> 1; apply a vector.
> 
> or even 
> (1 v) -> 1; apply a number to a vector. 

Ok, this is outside the scope of what I'm thinking about, I think :-)

Toby.