www.delorie.com/gnu/docs/kawa/kawa-tour_18.html

search

	Buy GNU books!

Kawa: Compiling Scheme to Java

1.17 Low-level procedures

Using a named global Procedure object has a bit of overhead. We refer to it by name, and finding the right Procedure is done by a run time name lookup. Once we have the procedure, we do a virtual method call to apply the procedure, which is relatively fast, but we would like to be able to inline known functions. Also, in the future, we want to support type declarations and the use of machine types such as int. Having to convert an int to an IntNum just because that is what the apply interface requires is expensive.

Another problem is that being able to call a Java method from Scheme requires writing by hand a new Procedure subclass. This is not a friendly interface.

The plan is to provide new syntax for defining Scheme procedures in terms of Java methods. The syntax will look something like:

(define-virtual exec-process "java.lang.RunTime" "exec" "java.lang.Process" ("java.lang.String")) (set! ls (exec-process "ls -l"))

The primitive syntax define-syntax defines a PrimitiveProcedure object (which inherits from PrcedureN), which refers to a named virtual method in a named class with specified parameter and return types. The primitives define-static and define-interface are similar, but for static and interface methods.

When the compile method of ApplyExp sees that the function is a PrimitiveProcedure, it will emit code to call the method. It will also emit code to coerce the arguments to the required types. It will not do any checking that the method actually exists and has declared type, since the method may not be available yet (and it is also a pain to do, though the JDK 1.1 reflection facility will make it easier).

The name declared by define-virtual has the same scope as that of a macro. It must be seen at compile-time. A PrimitiveProcedure cannot be applied or called at top-level interactively.

We can lift these restrictions when Kawa switches to JDK 1.1 and its reflective features. In that case, using a PrimitiveProcedure may be the preferred way to define many builtin functions. The advantage is simpler declarations, fewer standard classes, much faster invocation when the compiler knows which method is being called, but at the cost of somewhat slower calls when we have to use the general applyN interface, which would use the probably slower reflection facilities.