This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Getting rid of the "edit-compile-run-cycle" for Kawa
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/