Re: block-scope finalization

On Thu, Jan 14, 2016 at 1:38 PM, Tom Sutcliffe <tomsci@me.com> wrote:

On 24 Nov 2015, at 4:52 pm, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

> What is wrong with the following proposal?
>
> local <some mark to be invented> name = exp
>
> Unlike a regular 'local' declaration, this one must define only one
> variable and it must be initialized. (Both restrictions could be easily
> removed; they are more about programming style.)
>
> When the local 'name' goes out of scope, then:
>
> 1 - if its value is a function, that function is called (no parameters)
> 2 - if its value is a table/userdata, its __close (or some other new
> name) metamethod, if present, is called.
>

I do like the sound of that. It nicely sidesteps the whole GC-vs-refcounting scoping debate, because it won't be finalising or deallocing the value concerned, only calling its __close metamethod, which really is all I've ever wanted from such a construct.

I agree that doing something about this issue is better than doing nothing at all. The issue is quite real. Yet, the mechanism proposed by Roberto is a low-level mechanism and I would like to repeat what I wrote earlier on the subject:

(begin)

But I do not like the idea that Lua programs need to be using lowest levels of abstraction and micromanagement that comes with that.

If we forget, for a second, "external" resources. such as files, then Lua's internal resources (memory) are managed automatically. The user does not have to deal with that at all, at least in principle. Why should that be different for external resources? The only reason the user has to be involved now is because the language does not provide any means of deterministic finalization to library writers. If we decorate Lua with additional low level means of resource management, they should primarily be means available to library writers; we should not make the user even MORE involved.

On the other hand, if those new means require library writers to follow some new paradigm, then we cannot expect they will be universally adopted. We will have a mess not unlike what C++ is, with its multiple resource management paradigms. The proposed reference counting mechanism ensures that neither users nor library writers need to do anything new. We just improve the behaviour of all the existing code, and let users write simpler yet more efficient code in future.

(end)

I do not really care about ref-counting per se. I only mentioned it because that is the mechanism I am familiar with and also a mechanism widely used for this purpose. What I really want is something that is simple for all developers, including library writers, yet effective. I would list our options thus, more preferable (to me) first:

1. Deterministic garbage collection for all objects without new metamethods and without new language constructs. Optional metamethods controlling this are OK.

2. Deterministic garbage collection with new (not optional) metamethods but without new language constructs

3. Deterministic garbage collection with new language constructs.

4. Block-exit metamethod invocation without new language constructs.

5. Block-exit metamethod invocation with new language constructs.

Roberto's proposal, just like my initial proposal, is #5, least preferable to me, because both library users and library writers need to know and use the new mechanism, and the mechanism is somewhat awkward because the library writer does not really know that the object for which __close is called will not be used again; basically, the user has to ensure that.

Cheers,