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

[Helmut Eller <eller dot helmut at gmail dot com>]

* Ethan Herdrick [2008-05-03 14:21+0200] writes:

[...]
> In trying to achieve this I've made a simple macro "require/smart"
> that will expand to (require <foo>) if the system is in production
> mode, and expand to (load "\some-path\foo.scm") if in development
> mode.  Of course, our existing code behaves somewhat differently when
> loaded instead of required.  I've been working through this but I'm
> not sure what the ultimate result will be.  I might be overlooking
> some fatal flaw in this plan.  This technique does work fine in a very
> simple proof of concept with a very simple tree of dependencies made
> up of three simple files of definitions.

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.

> In an old post to this list (found here:
> http://www.sourceware.org/ml/kawa/2006-q4/msg00002.html )  Per wrote:
>
> "...you can:  (require "file-name")  and it automatically compile sit,
> as a module, and recompiles if it has changed.  It updates the global
> environment. (However, there is no support for updating existing
> values -such as if an existing value references an updated function -
> but that could be added.)"
>
> That would be fantastic.  What would need to be done to add that?
> Could it understand dependencies, i.e. recompile a class if a class it
> depends on has been recompiled?  That kind of dynamic dev environment
> - combined with Kawa's impressive performance as a compiled language -
> would really be amazing.
>
> Thanks in advance for your thoughts!

I think recompiling alone isn't enough.  The existing instances of the
old version should be updated too.  Some JVMs support class
redefinition.  That could be used, but it's probably the sledgehammer
solution.

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.

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

Just my 2 Cents.

Helmut.