"Image-based development" with Kawa

[Per Bothner]

Oliver Flasch wrote:
> This is interesting. However, my system does not have the concept of a
> "source file" per se. Would it be possible to implement a "compile"
> macro/procedure, which would take a list of expressions and compile them
> as if they where contained in a source file passed to "compile-file"?

It should be trivial to generalize to a Reader (i.e. a sequence of
characters), but taking an intermediate list structure may be harder.
The Kawa compiler interleaves reading (chars -> lists) and expansion
(lists -> internal form).

>> Make sure <my-class> "references" the enclosing module, so it gets
>> serialized.  You can probably do that by serializing its ClassLoader,
>> which is an ArrayClassLoader (see below).
> 
> Can you give me a hint on how to get hold on this ArrayClassLoader when
> the class has been defined in a read-eval-print loop (where all
> interaction with my system actually takes place, I am not using
> "compile-file" at all, at this point in time)?

I think you answer your own question later.
> 
> Sorry if this is a stupid question to ask, but it might help my
> understanding a lot if you could comment on the following behavior I
> observe in a Kawa read-eval-print loop. I am using the <2d-vector> class
> from the Kawa docs (which has some methods defined):
> 
> #> (define-simple-class <2d-vector> () [...])
> -> undefined
> 
> #> (*:getMethods <2d-vector>)
> -> #!null ;; no methods defined?
> 
> #> (*:scale (*:add (make <2d-vector>) (make <2d-vector>)) 1.0)
> -> $N2d$Mnvector@992bae
> 
> #> (*:getMethods <2d-vector>)
> -> $N2d$Mnvector.add($N2d$Mnvector)$N2d$Mnvector
> 
> #> (*:getClassLoader (*:getClass <2d-vector>))
> -> sun.misc.Launcher$AppClassLoader@133056f ;; an AppClassLoader, not an
> ArrayClassLoader?

Note that the "value" of the name <2d-vector> is an instance of
gnu.bytecode.ClassType, not an instannce of java.lang.Class.  The
reason is ClassType can be used to name a class at compile-time
that doesn't yet exist, since it hasn't been compiled yet.

This causes some confusion.   It may be possible to revisit this
separation, but I haven't thought through the issues involved.

> 
> I learned from your "Kawa internals" paper that "non-simple" forms, like
> class-definitions, passed to a read-eval-print loop are in fact wrapped
> into a ModuleBody which gets rewritten into a ModuleExp. This is then
> compiled to bytecodes forming a Runnable class. In the case of a
> class-definition, the interactively defined class would be represented
> as an inner class of this Runnable class. If I understand you correctly,
> the bytecodes are then loaded via an ArrayClassLoader and the Runnable
> class is run. The solution to my problem then would be to get hold of
> this ArrayClassLoader and serialize it together with the ClassType
> object representing the interactively defined class. When de-serializing
> the class, I would have to de-serialize the associated ArrayClassLoader
> and register it as a parent of the current ClassLoader.

The last part sounds strange.  It makes more sense to de-serialize the
ArrayClassLoader, and get load the serialized class from the copied
classloader.

> Could this work? If so, it would be possible to allow "image-based"
> development in Kawa/Scheme, which would be a very important feature for
> the domain I am working in.

Let's hope so!
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/