On 9 January 2014 16:53, Jonathan S. Shapiro <[email protected]> wrote:

> On Wed, Jan 8, 2014 at 5:07 PM, William ML Leslie <
> [email protected]> wrote:
>
>> It looks a bit like the real distinction is not the interface or
>>  instance definition at all, but about whether a function will treat
>> the instance as a compile-time constant argument or accept a vtable as
>> an argument at runtime.
>
>
> In a type system that does not admit prescriptively unboxed types, and in
> a runtime where unconstrained indirection is acceptable, this would be true.
>
> In a type system that *does* admit prescriptively unboxed types, but can
> constrain the lifetimes of interfaces, this would be "true enough".
>
> In a type system that admits prescriptively unboxed types and cannot
> guarantee interface instance lifespan subtyping, this is a mess.
>
>
>
Well, if you want to accept a polymorphic argument without doing any
templating, you need to at least know its size.  Functions that accept
something with interface type can reasonably expect that they are getting a
reference to the something.

(Typeclass) Instances in this case are vtables, and so are statically
allocated.  So the only actual magic is that you have a function that takes
an extra (hopefully implicit) argument, that vtable, together with a ref to
the value, and that the function has a region & effect contract specified
by the interface.

Since most interfaces will either end up on heap-allocated objects or will
be entirely non-escaping, the region types involved are likely of a few
canned varieties.  But I don't think they have to be.

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered under
copyright law.  You absolutely may reproduce any part of it in accordance
with the copyright law of the nation you are reading this in.  Any attempt
to deny you those rights would be illegal without prior contractual
agreement.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to