interactive development and code re-loading

[Per Bothner <per at bothner dot com>]

A major benefit of "dynamic" languages is "interactive development":
Use a repl, try some code, change the code as needed - and re-load
the changed code into the existing session.   Kawa is weaker in
this respect than some other languages, especially Lisps, where this
kind of interactivity is expected.  One reason is that Kawa does a
lot of inlining and type propagation: Say f depends on g, and you change
g but not f.  In that case the compiled version of f may have
baked-in assumptions about f that are no longer true.  Another
reason Kawa is weaker is that it tries to be close to the VM,
so a Kawa class is mapped fairly directly to a VM class, which
you can't change after creating the class and instances of it.

There are various mechanisms for improving the situation: The
main ones are indirection (less inlining), as well as automatic
re-compilation (if f depends on g, and g is changed, then
recompile f *and* g).  I won't go into details; getting to
something we're happy with will take a while.  (I do have
some patches that are close to go, which will help a bit.)

What I'd like to decide is *when* Kawa should use "interactive mode"
- i.e. to add indirection and automatic re-compilation.  The answer
is certainly not "always" because of the costs.  Having interactive
mode be controlled by flags is possible, but the more flags people
have to remember, the more confusion.  So having good defaults and
simple rules is better.

Note that "interactive mode" is a session property - in practice
that means it is a global property: Every time a file is imported,
required, loaded, or included - how the code is handled depends
on the "interactive mode" session property.  This property
could be a parameter (in the SRFI-39 sense) but it will normally
be initialized based on the kawa command line.

Starting a REPL (implicitly or using the "--" flag) should
obviously set the interactive mode property.

Running a file in whole-module mode (i.e. '$kawa foo.scm'), or
otherwise running a "script" should IMO *not* set the interactive
mode property.

However, running a file in line-at-a-time mode (with the -f flag)
*should* IMO set the interactive mode property.

I'm unsure about the -e flag, but that should probably also set
the interactive mode property.

PROPOSAL SUMMARY

There is a "global" is-interactive property (actually
stored as a field of the current ModuleManager instance).
It is initially false.

Each module (file or repl command) has an is-interactive,
property which is set from the is-interactive global.  This flag
controls how the module is compiled; how Kawa deels with any
"previous version" of a function/value/class; and whether
Kawa needs to keep track of dependencies.

We may add command-line flags to set the global is-interactive property,
though I'll wait to see if they're actually useful.

Entering a repl, or using the -f, -e, -c, or --script options
sets the is-interactive property.

Comments?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/