On 27 December 2014 at 07:10, Jonathan S. Shapiro <[email protected]> wrote:
> So here's my question: if we intend that i and f should be unboxed within S,
> isn't it sufficient to unify %r_S, %r_i, and %r_f?
>
> I understand that this doesn't address the question of placement within S.
> What I'm wondering is whether "unboxed" is best understood as a shorthand
> that means "unify my region with that of my container". In the case of a
> struct field, the container is the struct. In the case of a let-bound
> variable, the container is the frame (or more accurately, the scope, which
> is in turn contained by the frame). Conversely, "boxed" simply means that
> there is no presumptive relation between the two regions (though constraints
> might add such relations).
>
> I'm not sure whether this is practically valuable from a compilation
> standpoint, but it would sure be nice to simplify the core semantics if this
> seems plausible.
>
> Is this a sound interpretation of the meaning of unboxed and boxed?
Seems a bit awkward, whether you infer region variables and/or allow
them to be specified manually.
The region that contains the datatype you are defining (which is
probably parametric) should be considered special within the type
definition, because it is implied that it is at least as large as the
regions of its fields, and those implicit constraints need to be
maintained. And I think that in practice, you won't expect to force
the programmer to spell this out. More likely, they will write
something like:
datatype !mutability List ('a : Type in %ra) %rlist {
Nil : List 'a
Cons {
head : ref immutable 'a in %ra;
tail : ref !mutability List ('a in %ra) in %rlist;
}
}
And expect the compiler to understand this as "head has type 'a in a
region subsumed by %ra", that is, the %ra described in the final type
lives at least as long as both the head %ra and any element %ra's in
the tail.
The nice thing about this example is that even *if* the two %rlist
turned out to be the same, you may still want the tail to be boxed.
--
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
