This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: new Scheme()
Jim White wrote:
Thread isolation wouldn't seem to be the right thing to me because then
applications with multiple threads would have to know how to coordinate
to pass around the right environment and there wouldn't be a sensible
default.
The idea is each thread has a "current environment. Ususually,
its thread-specific, but inherits from the parent's thread's
environment, assuming the thread was created by (future ...).
In principle multiple threads can share the same environment
(as long as it's set up sharing), and it is possible to set
up inheritance between threads created other ways (but there
is no api for that yet).
Do the multiple languages in Kawa segregate the symbols with namespaces?
That would seem to me to be the right thing because it provides a dandy
balance of isolation and easy interoperation when desired.
They can, and that is the plan. For example, in Scheme I'd like
to be able to use common-lisp:equalp and in Common Lisp I'd like to
be able to use scheme:equals?
But what if I write 'eq? in Common Lisp code? The namespace-resolution
(package lookup) is done at compile time (actually read-time in
Common Lisp, but later in Scheme). Which pachage does it get bound to?
What about user symbols without a namespace prefix? Which namespace
/package are they resolved in at compile-time and at run-time?
Which prefixes are available? Are all prefixes available in all
languages automatically? Is xquery:local-name-from-QName automatically
defined in Scheme and Emacs Lisp?
What if I'm in Common Lisp and call (scheme:eval 'foo:bar) or
(scheme:eval-string "foo:bar") - what happens?
The current implementation is awkward, because the user interaction
environment inherits from the language builtins environment, which
makes it difficult to switch between languages. I think a
language-independent user environment is the right solution.
The notion of "current environment" may need to switch to a
"current search path" Perhaps we can use a "namespace search
path" rather than an "environment search path", but I'm not
sure yetk.
--
--Per Bothner
per@bothner.com http://per.bothner.com/