<div dir="ltr">From my perspective, there are two orthogonal things going on here:<div> 1. The idea of a "resource" with a well-defined protocol for allocation, initialization,</div><div>   deinitialization, and deallocation. Genera (and CLIM) had macrology for this:</div><div>   <font face="monospace, monospace">defresource</font> to define a resource, <font face="monospace, monospace">using-resource</font> to use it in a "safe"</div><div>   way such that all those things happened in order.</div><div> 2. Having <font face="monospace, monospace">let</font> behave like <font face="monospace, monospace">using-resource</font><font face="arial, helvetica, sans-serif">.</font></div><div><br></div><div>It would be perfectly simple to write a <font face="monospace, monospace">let</font> macro that shadows <font face="monospace, monospace">cl:let</font>, which</div><div>tracks allocation/initialization of resources, evaluates the body, and then calls</div><div>the deinitializer/deallocator. How you implement "resources" is up to you. :-)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 26, 2016 at 7:52 AM, David McClain <span dir="ltr"><<a href="mailto:dbm@refined-audiometrics.com" target="_blank">dbm@refined-audiometrics.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, finalizers can sometimes work. I have those in place. But they are tricky. Suppose I hand off a local channel to another thread to utilize of communication between us. Now there are two copies of that channel pointer. So when my local use goes out of scope, there is still one copy in use, by that thread. And that thread is likely just hanging, waiting for something to come across that channel, that never will, since it just went out of scope from the sending side. Hence GC will never have the opportunity to finalize.<br>
<br>
Instead, you have to invent contorted references to the channel that can be neutralized by the sender when it goes out of scope.  And I say contorted because these references have to be complex enough that the compiler won’t perform some stack optimization and produce an inadvertent secondary reference.<br>
<br>
So, for example, it isn’t sufficient to make a reference to a channel as (list ch) / (car ch). That seems to become unwrapped at the receiver side by things like handler-case, ignore-errors. Rather you have to use a functional closure like (lambda () ch) / funcall. And now we’ve lost the symmetry of use on each side of the channel.<br>
<br>
Not only that, but now we have to understand Lisp implementation details that we never needed to know before. And so we likely aren’t semantically portable.<br>
<br>
Secondly, as you mentioned, not all Lisp support finalization, or not very well. Lispworks does fine, but I find SBCL particularly weak in that you only get told about an object being scavenged after it has already happened. Hence you have to keep a display array and use indirect references in SBCL.<br>
<br>
What I recall from C++ world is that the automatic destructor calls at scope exit only happen on stack allocated objects, not pointers. Makes sense, since pointers allow for the possibility of alias pointers all over the place. Well, that’s exactly the situation we have in most Lisps too. In fact there can be no such thing as a stack allocated object, even if it really is allocated on the stack.<br>
<br>
So then we have to invent reference counting to be sure we don’t destroy a shared object pointer too soon.<br>
<br>
What I’m asking for really isn’t safe in Lisp. The best we can do, it seems, is what David proposes with his Scope macro, or my WITH- / UNWIND-PROTECT.<br>
<span class="HOEnZb"><font color="#888888"><br>
- DM<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
> On Aug 25, 2016, at 22:42, Nick Levine <<a href="mailto:nick@nicklevine.org">nick@nicklevine.org</a>> wrote:<br>
><br>
> Would finalisers do the trick?<br>
><br>
> Not part of the language itself, but many implementations support them.<br>
><br>
> Various caveats apply. In particular you cannot guarantee when (or I guess whether) any particular resource will be finalised; only that the GC will get around to most resources in the fullness of time. So this solution might not meet your needs.<br>
><br>
> - nick<br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>