Re: Kawa and BSF

[Per Bothner <per at bothner dot com>]

Allan Erskine <a.erskine@cs.ucl.ac.uk> writes:

> First, why throw a RuntimeException in the eval methods, even if it's just a
> gnu.text.SyntaxException?

Because otherwise things get really painful.

> This seems a bit brutal, especially if using Kawa > as a scripting
> language within another framework (which may want to catch > and
> handle Kawa errors)?

So what is a "Kawa error" as opposed to any other error that may be thrown
from a Kawa procedure?  Is an array-index out-of-bounds a "Kawa error"?
Why not?  What would you do with a "Kawa error" that would be different
from what you would do with a "non-Kawa error"?

  How about having a KawaException class as the
> worst case (intentional) throw (like the PyException of JPython)?

Because then everything *including any Java code that may invoke Kawa
code* has to declare KawaException.

> Secondly, multiple instances of a BSF engine can co-exist across many
> threads.  It looks like I'm able to have a separate Environment for each
> engine,

Plus a separate instance of Scheme.

> but when it comes to evaluating using the Scheme class, everything
> in sight seems to be static.

The design issue is how a Scheme procedure is compiled to a method:
Should the "Scheme state" be an explicit parameter to the method,
or should it be implicit?  If the former, then you basically have to
carry around a "Scheme environment" everywhere, which makes Scheme-Java
integraton more difficult.  Instead, the idea is that the Scheme state
is an implicit paramater, which is tied to a specific thread.  See
the getCurrent method in Environment.

Admittedly this model hasn't been implemented as consistently as it
should be, but at least the basic support is there, I believe.

Note this is talking about the current default calling convention.  If
you set --full-tailcalls then a different calling convention is used,
which has an extra CallContext parameter.  I've got recent
(un-checked-in code) which increases the use of CallContexts, so that
top-level ModuleBody instances use the calling convention using
CallContext.  Also, new eval method in Expression take a CallContext.
It seems plausible that we may at some point integrate the CallContext
and Future classes, or at least have the per-thread CallContext refer
to a per-Scheme-engine Future.

> At the very least it looks as if the evalBody
> method of Eval ought to be synchronised.

Why?  It's an internal routine; if things should be synchronized,
it should be the higher-level user routines.

Note that the Kawa model is that if you have multiple "Kawa engines"
they shoule be separate Futures; in that case evalBody should do
the right thing.

My understanding is that Java experts now agree that the
"synchornize everyting" model of JDK 1.0 was a mistake, as
doing so costs you a lot of performance, without necessarrily
making progrtams any more thread-safe.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/