On Thu, Feb 26, 2015 at 3:16 PM, Matt Rice <[email protected]> wrote:
> On Thu, Feb 26, 2015 at 6:37 AM, Jonathan S. Shapiro <[email protected]> wrote:
>
>> The ObjectHeader contains a type code for the object, and there are a very
>> few procedures associated with these objects that dispatch on the type code,
>> but no virtual overrides occur in this scenario.
>
> I don't suppose we have any specific numbers on object types, and
> number of procedures common to them, in that the sml code i keep
> hammering on about specifies a common implementation of a common
> procedure via a type constraint specifying a partial type, but this
> leads to a type * procedures instances of procedures common across
> types,
>
> in general this works well in my case because the number of types and
> common procedures is in fact low.
So, I think the above is somewhat easily dismissed, the theory though
is hopefully we can agree that given some class heirarchy we can
generate duplicate symbols class1Foo() class2Foo() and flatten out the
vtables and get some kind of equivalent but static program...
so then if we introduce type constraints instead of class heirarchy we
can define some function foo(this:'a where {#name='b;'Z}) = #name this
and end up with symbols T1.foo and T2.foo when T1 and T2 satisfy the
constraint...
A deeper inference on the constraint gives us the offsett of #name
into 'this', and the type returned, etc, and this gives us a basis for
judging the equivalence of T1.foo and T2.foo, and a way to compare the
compatibility of a deeply infered constraint with a type as a basis
for whether its safe to cast
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
