Kawa: Compiling Scheme to Java
1.20 Classes, types, and declarations
An extensive type system that supports user-defined classes is
important for extensibility and for integration with other Java packages.
This section describes current ideas for future extensions.
The record extension proposed (and rejected) for R5RS will
probably be added. It has been partially written; however
a new implementation based on the JDK 1.1 reflective features
seems preferable, since that means the record accessor
features can be used on arbitrary Java objects.
After than, the next step is to add methods, and we have a way to define
and access Java classes from Scheme.
Type declarations and some form of first-class
types are also planned. This will improve documentation,
error-checking, and code efficiency. Among the types to be
supported are "unboxed" number types, so the compiler
could use raw double instead of having to allocate
a DFloNum object. In addition to allowing better code,
this feature will also make it it easier to integrate with
primitive Java types. (The define-virtual syntax in
1.17 Low-level procedures will be extended to support type values.)
Some kind of module system is desirable. One reason is to
control names and names clashes; another reason is so that
the compiler can map global variables references to their
definitions. This makes it easier to do better optimizations.
It is tempting to define a module as a kind of class:
A simple module is a packaging of data and function definitions,
and it is easy to map these into static fields and methods of a class.
Controlling which components are exported is similar to
specifying visibility (public or private).
What is more challenging is how to model import lists,
or module signature/interfaces. Perhaps we can use Java interface types.
Given all this new infrastructure (types and modules),
then the compiler will need some re-writing. At the very least it
needs to know that expressions may have other types than just
plain Object.
