Re: [bitc-dev] [SPAM] Thoughts on GC-style resource management

[Sandro Magi]

You claimed in a subsequent message that linear types can handle many, but not all usage scenarios to which you allude below. Perhaps a more fruitful approach would be to provide one or two examples of resources or usage patterns that can't be handled linearly, or perhaps can't be handled linearly and "modularly"? The Rust devs spent a lot of time and code exercising their linear types and borrowing system, and they seem to have achieved something pretty usable overall. The specific failures of this approach might elucidate specifically what you're concerned with. Sandro On 05/08/2015 9:40 AM, Jonathan S. Shapiro wrote: I've been listening to some talks on GC, and they raise some questions in my mind about resource management. I'm not focused on the memory part here, so much as the management of *other* resources. I haven't done any programming "in the large" using GC-style resource management. Patrick Dessault notes, correctly, that GC makes things modular. He means this in the sense that the desire for opaque (or more precisely: oblivious) behavior across a module boundary is violated by explicit memory management; we can't release memory when we don't know what's been done with it, and we don't have any good ways to specify the contract at the module boundary. So GC solves this for memory, but it doesn't really solve this for other resources that we might need to allocate and deallocate. Finalizers can do this, but I there is a general consensus that finalizers should be view as a "last gasp" recovery mechanism. Mainly because the kinds of resources we tend to be talking about are both precious (that is: in limited supply) and coarse (that is: there is a lot of incentive not to hold them longer than we need them). This how we get to patterns like the destroy/finalize pattern that exists in .NET and elsewhere. But it seems to me that this leaves us with the modularity problem unsolved. Improved, certainly, but unsolved. What's the sense of things on this? Is this viewed as a real issue in practice? shap _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev

_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev