Re: Kawa Generic Functionality

[Per Bothner <per at bothner dot com>]

Nigel Dolby wrote:
> As I port Common Lisp code into Kawa there are a number of things that 
> would make the process easier, and it would be nice to know if there are 
> ways to do these and what they are.
>
> 1. The Common Lisp function TYPE-OF accepts absolutely any object and 
> returns its type as a symbol; this includes CLOS objects, for which the 
> CLOS class is returned. I have written a Kawa function that partially 
> implements TYPE-OF by explicitly checking for string, integer, etc in a 
> COND, but is it possible also to reliably obtain the type of objects 
> defined with DEFINE-SIMPLE-CLASS and of Java objects (without knowing 
> that the object in question actually is such a class)?

Well, to get the name of the Java class of object X, you can always do:
  (*:getName (*:getClass X))
Or if you want a Scheme string (rather than a Java string):
  (make <string> (*:getName (*:getClass X)))

> 2. CLOS classes can be given a PRINT-OBJECT method which allows 
> customization of the displayed form of an object of that class. I have 
> tried attaching a toString method to Kawa classes (made with 
> DEFINE-SIMPLE-CLASS) but this doesn't produce the same effect; is there 
> a way to do so?

You could have the class implement gnu.mapping.Printable, which uses
a print(java.io.PrintWriter) method.  The latter can be customized to
do pretty-printing if the argument is a gnu.mapping.OutPort.

Unfortunately, formatting and printing is hard.  A complication is that
we may want language-specific output of standard Java classes, so to
some extent we have to use type tests rather than inheritance.  So I
don't think we have the "right" formatting framework for Java yet
- though hopefully it's close enough to what you need.

> 3. I have a function called COPY-CLOS-INSTANCE which clones a given 
> instance, optionally using COPY-TREE on any lists it contains. It 
> operates by creating a new object and copying each existing slot value 
> from the old to the new object. I need this in Kawa. I first tried to 
> use the Java 'clone' method, but this generated a protection error at 
> compile time.

You need to have the class implement java.lang.Cloneable:
(define-simple-class <MyClass> (<java.lang.Cloneable>) ...)

Having define-simple-class automatically implement Cloneable
would not be appropriate, though we could consider it for classes
defined using define-class.

> I find that I can obtain the fields of an instance in Kawa 
> by invoking getClass followed by getFields, but I have not found any 
> definition of the Field objects that are returned.

It's a standard Java class: java.lang.reflect.Field.
Note Kawa also has: gnu.bytecode.Field.  The duplication is because
the latter is also available for classes that don't (yet) exist.

> So my code currently 
> invokes toString on the Field objects and unmangles the last part of the 
> returned string to get the Field name. Is there a more elegant way to do 
> this?

The question is what are you trying to do: Why do you want to copy an
object?  What are the intended semantics?  Deep copy or shallow copy?
A general dumb copy operation has limited usefulness.

> 4. When a piece of code breaks and control returns to the Kawa 
> interactive window, a backtrace is provided that (usually) locates very 
> closely the offending source line; is it possible at that point to 
> inspect the local variables?

Yes and no.  The backtrace is produced by the standard Java printStackTrace
method.  The standard classes or JVM do not have access to local variable
names.  They are available in the .class file, and one could search for
the class file using the CLASSPATH.  However, you still can't find out
accurately which local variables are in scope, because the stack trace only
gives the line number, not the bytecode offset.

The solution is to use a debugger.  The SchemeWay project
(http://schemeway.sourceforge.net/) provides a Scheme plug-in for the Eclipse
IDE.  It is primarily a Scheme source-code editor, but it can be used to
example stack traces, including local variables, and set breakpoints.
However, it isn't very Scheme-aware, so it uses mangled variable/field
names, doesn't know anything about Kawa's calling conventions and closure
representation, displays values using inappropriate formatting, etc.

I'm hoping somebody will spend the effort to make Eclipse into a nice
Kawa debugger, suitable for people not experts in Java or the Kawa->Java
translation.

Another approach may follow from planned work to implement full call/cc.
For that, we will need a more Scheme-accessible representation of the
cal stack - in which case the standard Java printStackTrace will be
even less helpful.  The overhead of getting Scheme variables names etc
when using this representation should be modest.  (Note that is because
supporting full call/cc will generate much slower code, so it will probably
not be the default.)
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/