On 8 January 2014 09:20, Jonathan S. Shapiro <[email protected]> wrote: > On Sun, Jan 5, 2014 at 11:33 PM, William ML Leslie > <[email protected]> wrote: >> Well, the question is, how should I do /this/ in bitc? Do I not do it? > > > I'm not sure that /this/ is actually helpful in BitC. I suspect it depends > on whether adopting private/public is motivated. In the absence of > inheritance, /this/ really has no special properties at all. The procedures > that initialize the ifTable of a given interface are free to name the > parameter corresponding to the existentially encapsulated reference whatever > they wish - formal parameter names aren't part of the procedure signature.
Actually I meant /this/ metasyntactically, representing some idiom of interface usage. Ah, the difficulties of discussing language. >> The "immediately cast to an interface" pattern for example is pretty >> common. I often want to store collections of some interface, in >> particular. > > > Indeed. And that's part of why I was so careful about wording the lifespan > rule to be "an interface may not outlive the thing that it references". In > the kind of pattern you are talking about, the object tends to be heap > allocated. Either that or we know something about it's region. In either > case we can rely on GC and there is no problem storing the interface in the > collection. And in either case we can rely on region typing to tell us when > we have done something wrong in this regard. Excellent, that's what I was feeling. > But my personal opinion is that this should not fail by putting V in the > heap. I think it should fail by reporting that r(W) > r(V), and telling the > programmer that (a) placing V in the general heap, or (b) more carefully > specifying the region containing V is the right solution. Indeed. > Hmm. Maybe that's too strong. It seems pretty clear that the compiler > shouldn't go magically moving things into the heap when we are under a > noheap constraint. The more problematic case is when the effect type is > parametric. In that case, from a local partial typing perspective, we may or > may not end up under a noheap constraint. The problem in this case is that > moving an object into the heap "fixes" the noheap constraint to !noheap, > where we may really need to be able to instantiate either way. This is probably a discussion for another thread - it's a question of what we can and can't do with region and effect types. I don't think this problem occurs for interfaces, however you want to represent them: they are immutable and so can be copied as needed and should probably be value types; so the issue is the region constraint that they propogate from the underlying object. If you're allocating the underlying object here and passing it to a provided function, the region of allocation is parametric, and there are several implementation techniques. However, if interfaces are value types, then satisfying region constraints can usually be left to whatever function we pass the interface to (if it wants to store them on the heap somewhere, it can allocate an interface instance on the heap). -- 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
