I&#39;m by no means a compiler designer, so please forgive my clumsiness with jargon. <br><br>I would imagine that it would be hard to know how many heap allocated objects (closures, etc) would be created over the course of a program. How long they would live seems like a much more tractable problem. It seems that an object&#39;s lifespan can in most cases be guaranteed by the frame on which it was created. If not, a simple set of rules (and the fact that the compiler understands the program it is creating) could control such things.<br>
<br>There are situations where a garbage collector is not desirable, but I would prefer to avoid the errors of explicit memory management. <br>With this in mind, would it be possible to have a compromise between  full GC and no memory management (at all?) by using a pool allocator which is scoped to a particular frame. <br>
<br>This pool, as pools go, would be created with an amount of free memory could and replenish itself if necessary up to a maximum amount. This has a side effect of making the program execute faster, but it would also increase the memory usage considerably if managed incorrectly. <br>
<br>The challenge is ensuring closures don&#39;t escape their &quot;scope&quot;. I was thinking that perhaps a lambda could be returnable but not copyable, and would be scoped to the frame of calling function.  I vaguely recall reading somewhere that when building in no-gc mode, BitC will disallow certain features in order to avoid heap allocation. Would those cases be covered by such a scheme? <br>
<br>-- <br>We can&#39;t solve problems by using the same kind of thinking we used when we created them. <br>    - A. Einstein<br>