
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 16-apr-11, at 22:49, Timon Gehr wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><font class="Apple-style-span" color="#006312">[...]</font></div></blockquote><blockquote type="cite"><div>The problem is, that inside a non-leaky pure function the general case for dynamic<br>allocations might be just as complicated as in other parts of the program.<br></div></blockquote><br></div><div>indeed, this is exactly what I wanted to write, yes in some cases, one can get away with simple stack like, or similar but it breaks down very quickly.</div><div><div>In fact GC were introduced by functional languages, because they are kind of needed for them, already that should hint to the fact that functional, or pure languages are not intrinsically easier to collect.</div><div><br></div><div>What can be useful is allowing one to add a set of pools, that then can be freed all at once.</div><div>Having several pools is also what is needed to remove the global lock in malloc, so that is definitely the way to go imho.</div><div>Then one can give the control of these extra pools to the programmer, so that it is easy use a special pool for a part of the program and then release a lot of objects at once. Even then one should put quite some thought into it (for example about static/global objects that might be allocated for caching purposes).</div><div>A strictly pure function returning a value without pointers gives guarantees, but as soon as some caching (even behind the scenes) goes on, then things will fail. If a separate pool is used consistently for cached or shared objects one should be able to allow even caching.</div><div>All this comes back again to having several pools, showing how useful such a primitive is.</div><div><br></div><div>Fawzi</div><div><br></div></div></body></html>