On 4 January 2014 12:40, Jonathan S. Shapiro <[email protected]> wrote:
> In my initial discussion with Ben, I kept getting hung up on the fact that
> Interfaces are reference types. This means that every operation that obtains
> an interface from an object is an allocating operation.
I don't think this really has to mean that they are allocated on the
heap, I mean, they could be:
* fat pointers
* allocated at a given offset - a type is cast to a certain interface
by adding an offset to the base pointer, so that the value at the
offset is the interface vtable. In a gc'd system, the vtable can be
used to describe the layout of the underlying value. I really think
this is much nicer than how hotspot implements them.
Either of those seems more appropriate for heap-free programming.
> Does this idea that instances of interfaces have a lifetime restriction
> work? What do people think?
I like it.
Does it work? Well, without having formalising it in a Tofte-Talpin
derivative; I /think/ it works. This is one of those cases where it
would be convenient to run an analysis over a large body of code to
see if this is how people are using interfaces, and for those cases
that they are not, how often one of the obvious solutions can be used.
And by that - I should say - that there are cases where wrapping (via
object composition) the value with the interface is the appropriate
thing to do. It's very common to say, in Java,
final Set<Label> regionLabels = new HashSet<Label>();
where it is clear to the programmer that there is one type that is
controlling the lifetime and another that is only used in a borrowed
fashion; here, as the 'this' pointer in any method invocation on the
set.
Dependant pairs or linear types describe the cases under which
composites can live within return values or global regions, excepting
that allocation of the value remains a pain in the neck. But, I know
you don't want to have these.
And of course, interfaces on pure types or types in a value-only
position are possible to implement via copying if necessary, but I
don't think I would want silent (or nearly-silent) copying if I don't
want heap allocation.
> Note that if the underlying type is a reference type, this doesn't really
> impose any meaningful restriction on the corresponding interface objects.
> When it's challenging to resolve the lifetimes, the compiler will just end
> up pushing both the reference object and it's associated interface instance
> into.
into?
I guess you were going to say 'into the heap'. How will the error
message look in heap-free programs? It will occur (that is, be
detected) in the function where the region of the value appears free
in its body, and the region of the interface appears in the latent
effect of the function or in the flattening of the return type. I
think the error message also wants do describe where the interface is
extracted from the value.
--
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
