On Sat, Jul 27, 2013 at 10:11 PM, David Jeske <[email protected]> wrote:
> On Sat, Jul 27, 2013 at 8:29 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> On Fri, Jul 26, 2013 at 10:01 PM, David Jeske <[email protected]> wrote: >> >>> On Fri, Jul 26, 2013 at 7:56 PM, Jonathan S. Shapiro >>> <[email protected]>wrote: >>> >>>> ...What I *am* hoping to do is to use compiler magic to reduce the >>>> utilization of the GC heap so that GC pressure and/or total RAM >>>> requirements are suitably reduced. >>>> >>> >>> ...Understood. Let me rephrase my point. Using this magic is a necessary >>> but not sufficient condition to achieve a practical typesafe GC-free >>> capability. >>> >> >> Agreed. So let me say it one more time: That. Is. Not. A. BitC. Goal. >> > > I misunderstood. Your comment about the allocation-free main deduction > confused me. I thought it would never allow non-safe memory use, not that > it would always use GC. I understand now. > I don't think so, because I think we are still talking past each other. If BitC resumes, the forward direction of the language will fully support regions as first-class entities, which is pretty powerful as a collection mechanism. It's not perfect, and it's not everything. Based on the experiences of Singularity, I do *not* think that linear types are terribly helpful. The experience was that programmers couldn't understand them. Unfortunately, there are some very common code patterns that linear types just can't deal with where [dynamically] unique pointers can. Might be something to explore. BitC-forward would also provide an effect system with effects constraining GC, and I'll come back to why that's important in a minute. > > What kinds of libraries were they interested in where GC was a concern? It >> also occurs to me to ask: why is the Rust team trying to eliminate GC? >> Where did it get in the way, and is it an inherent consequence of GC or is >> it a consequence of a poorly implemented GC? > > > These are good questions. This blog post offers some commentary on the > issue. It sounds to me like it's not so much that they are trying to > eliminate GC, but that they want to be able to write Rust code without GC's > costs, which led them to owned-and-borrowed pointers, and then they decided > they'd like to focus on that for the core and push GC out for now. > > http://tim.dreamwidth.org/1784423.html > I read the post, but I don't see anything in there explaining why GC was a problem. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
