On Wed, Jan 7, 2015 at 11:27 PM, Jonathan S. Shapiro <[email protected]> wrote: > On Sun, Jan 4, 2015 at 1:07 AM, Matt Oliveri <[email protected]> wrote: >> I sort of like this way of elaborating the code. I like it because >> what I think it's essentially trying to do is make the use of l-values >> explicit. But I don't like it because l-values are not ref's; they are >> not first class. (They can be made first class with pointers, of >> course, but we don't want to put in extra pointers just to optimize >> them out, do we?) > > That's one way to view things. Another way is to note that the > l-value/r-value distinction only exists in the first place because of > unboxing.
That's a weird thing to say. Even without anything struct-like at all, there's a difference between referring to a local variable, and referring to the current value of the local variable. ML doesn't need an l-value/r-value distinction because it doesn't think of variables as slots for values, but simply as (abstract) values. Maybe I should've spoken of slots, instead of l-values, in my email. In SML, refs are the only place where you need to acknowledge the existence of slots. So the things that are "really" operations on slots can instead be thought of as operations on refs. But this is a hack! OCaml is similar, but the only kind of slot is a mutable field of a record. Note that here, an individual slot doesn't correspond to a value of any type. But even so, the slot operations are all lumped together as record operations, which, again, technically works. Your elaboration is trying so hard to avoid slot annotations, by turning slots (or maybe just local variables?) into refs. Yes, this does strange things to unboxing, but I wouldn't say that slots vs. refs is a matter of unboxing just because that's coincidentally true in SML, where slots always come with a box. > In the scheme I proposed, ignoring obvious optimizations, all of > the (initially) stack-allocated things are constant reference bindings. > There's a huge loss of performance here if we implement this naively, but > there is no inherent loss of abstract expressive power. What, exactly, is the "abstract expressive power" that is not "inherently" being lost? Clearly, we are losing the ability to literally have unboxed values in variables. What I would like to be true is that the elaboration process is injective, so that we could realistically hope that the optimizer would reverse the damage. Maybe that's what you're claiming. Another thing that seems true is that mutability checking could be implemented by elaborating the code, and doing type checking in a no-unboxed world. Maybe that's what you're claiming. But either way, thinking about slots or l-values seems more "honest" about the situation, and I don't see why we would want to eliminate the notion of l-value annotations at any point in compilation before the l-values themselves are compiled down to temporaries/pointers. ---- However, what I think is more important, and which you haven't commented on, is the idea that readonly does not make much sense as an annotation on an arbitrary type. It should be an annotation on l-values, or at least refs and record fields. In other words, there is no such thing as a "readonly int". There is a readonly _variable_ which holds an int. Or there is a readonly _ref box_ which holds an int. (And that ref box may have been upcast from a read/write ref box.) _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
