At 08:14 PM 10/25/99 , Per Bothner wrote:
>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.
This sounds like an exact correspondence.
>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);
> }
>}
Sorry, I didn't get it. Could you provide some examples?
>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.
If I follow this, it would all seem relevant to E as well. I look forward to understanding how our worlds may relate to each other.
Cheers,
--MarkM