Getting rid of the "edit-compile-run-cycle" for Kawa

[Per Bothner]

Helmut Eller wrote:
> I also think that Kawa needs improvements in this area.  I'd love to see
> support for R6RS/ERR5RS style modules, which, I think, would solve some
> of the dependency tracking problems.

Kawa does support the concept but not the syntax of R6RS/ERR5RS style
modules.  Kawa doesn't support selective import (only importing some
of the exported names) or renaming on import.  I don't think those
would be difficult to add.

> I think recompiling alone isn't enough.  The existing instances of the
> old version should be updated too.

That's harder.  A partial solution would be if the body of a function
changes, to modify the function in place so the old function object
now has a new body.

> Some JVMs support class
> redefinition.  That could be used, but it's probably the sledgehammer
> solution.

It would be nice to look into the options

> For my needs it would be sufficient if all top-level-functions in a
> module --also those which aren't exported-- were indirectly called
> through a location.  [A bit like in Common Lisp where
> top-level-functions are indirectly called through the symbol-function
> slot.]  When it's time to upgrade a module the existing locations must
> be updated with the new values, so that calls are redirected to the new
> version.

All the top-level functions are represented by a ModuleMethod object,
which provides the needed re-direction.  We do need to limit the
inlining so calls work through the ModuleMethod, rather than going
all the way down to the static method.

> This should also somehow work for multiple threads.  After updating a
> module I usually want that all threads use the new version.

That would heppen automatically if they use the ModuleMethod for calls.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/