Re: A New Revealation: Semi-Permeable Membranes Per Bothner (per@bothner.com)
25 Oct 1999 20:14:05 -0700

"Mark S. Miller" <markm@caplet.com> writes:

> Of course, for the normal cases a good compiler is expected to compile away all the extra implied overhead. Since some optimizing Scheme compilers (eg, Orbit) transform some "locations" (the scheme semantics term corresponding to our Slots) into reified objects in an intermediate stage of transformation, only to make it collapse out later, we may be in luck if we use compiler technology built for Scheme. Per?

Well, Kawa has most of the hooks you need, I think. Simple variables are represented using simple Java fields or local variables, having either primitive or class type. If the the location operator is applied to a variable (an l-value), you get (I guess) a "re-ified" value, which has type Binding. In that case, getting/setting the value is automatically compiled to get/set method calls, while for simple variable setting/setting is compiled to primitive Java operations. A Binding is basically what you call a Slot.

The gnu.bytecode.Type is an abstract "type" concept, similar to your SlotGuard idea. It includes the following methods:

public abstract class Type {
...

public abstract Object coerceFromObject (Object obj);

public Object coerceToObject (Object obj) {
return obj;
}
/** Compile code to convert an object (on the stack) to this Type. */ public void emitCoerceToObject (CodeAttr code) {
}

/** Compile code to coerce/convert from Object to this type. */ public void emitCoerceFromObject (CodeAttr code) {
throw new Error ("unimplemented emitCoerceFromObject for "+this); }
}

In Kawa, all variables, parameters, and expressions have an associated Type. The compiler emits the needed coercions automatically. It is reasonably good about suppressing unneeded coercions.

A Type is a first-class value. Strictly speaking, when a variable (say) has a declared type, that type is an expression that is evaluated at compile time. However, the existing support is mostly for type "constants" - i.e. type expressions that can be evaluated at compile time. I've done a little bit of thinking onm the issue of "compile-time type" vs "run-time type" of an expression/variable, but this area needs further thought. I do have some idea for this, specifically for classes that are define inside a function. This is like Java "inner classes", but inner classes are not true first-class values: The Class object representing an inner class is a static class, and has no state representing the context. The plan is to create Type objects at run-time to deal with this case. 

-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/