This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]