I believe it has been implemented
On Wed, Jul 17, 2013 at 10:32 AM, Sandro Magi <[email protected]>wrote: > Here is Rust's proposal on regions: > > https://github.com/mozilla/rust/wiki/Proposal-for-regions > > > On 16/07/2013 10:01 PM, Jonathan S. Shapiro wrote: > > I want to expand a little on how the rust pointer types relate to the > > corresponding BitC binding types. I think Rust is confusing data types > > and region types in its current description of the semantics. > > > > BitC started with by-reference parameters, and soon added something > > that we initially called "ref" bindings. What happened was that we had > > a rewriting pass anticipating Henderson-style safe GC that created a > > local on-stack binding for every parameter, and we needed a way to > > record the fact that this binding must not get captured. The result is > > very similar to - and strictly more general than - a Rust borrowed > > pointer. > > > > Internally, we never bothered to introduce (by-ref 'a) as a > > first-class type. We treated those as being of type 'a with a marker > > bit indicating that the final code emitter needed to add an extra > > dereference. This ultimately created a problem, because it meant we > > couldn't check type class method type agreement when we went to do > > input streams, but that's a story for another day. The point is that > > until we hit the method overloading problem we didn't care, because > > by-ref parameters and by-ref bindings were guaranteed to be > > non-escaping by virtue of their lexical and syntactic structure. So on > > a parameter, BY-REF implied NOESCAPE, where in the internal let > > bindings LET REF would probably have been labeled better as LET > > NOESCAPE x = <intiializer> in .... > > > > Now here's the point: when a LET NOESCAPE binding is bound to a new > > allocation, it is necessarily the point where the allocated object > > must go out of scope. Further: objects allocated in this fashion > > necessarily obey a strict stack discipline in their allocations and > > deallocations. Further, if the underlying initializer can handle it > > and the size of the target object is know, the object can be stack > > allocated. And then the constraint is that such a binding can only be > > passed as a non-escaping parameters, and can only be captured by > > bindings that we know will go out of scope sooner than the dominating > > binding. > > > > In fact, the only time you /can't/ stack-allocate the value is when > > the size of the target type is unknown. Or when the target system > > imposes constraints on overall stack size or introduces stack red-zone > > problems, but those are problems of implementation that can be solved > > with a separate allocation stack. > > > > Very shortly thereafter it became apparent that something a bit more > > flexible than non-escape was needed. I decided we needed regions, but > > we never got to them. > > > > The point I think I'm trying to make is that NOESCAPE is actually a > > region constraint, and region constraints are strictly more powerful > > than the owning pointer notion. But more importantly, NOESCAPE and > > OWNED describe the /region type/ of a binding rather than the /data > > type/ of a binding. > > > > The other thing you get when regions are introduced is the ability to > > name, bind and pass regions as first-class types. At that point you > > can allocate objects within specific regions of the heap, and you can > > do both local GC's of that region and bulk deallocation of the region. > > > > Regions aren't a cure-all. It's very common for objects within a > > region to become unreferenced in real programs, and there are examples > > of obvious real-world programs in which automatically inferred regions > > grow without bound as a result. > > > > But if you're going to add them, I think it's better to do them in a > > first-class way, not as a bolt-on side effect of an unusual pointer > > type annotation /or/ an unusual binding type annotation. > > > > > > Jonathan > > > > > > _______________________________________________ > > bitc-dev mailing list > > [email protected] > > http://www.coyotos.org/mailman/listinfo/bitc-dev > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
