Re: block-scope finalization

[Coda Highland <chighland@...>]

On Tue, Nov 24, 2015 at 1:05 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> On 24 November 2015 at 20:59, Coda Highland <chighland@gmail.com> 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.
>>>>>>
>>>>>> Otherwise, 'name' is like any other local variable.
>>>>>>
>>>>>
>>>>> I haven't followed the whole conversation so apologies if I have got
>>>>> this wrong. If the aim is to provide a 'finally' type feature then an
>>>>> important aspect is that the finally code must execute even when
>>>>> exceptions occur. In the above proposal how will Lua ensure that the
>>>>> function will always be called when the block exits even if there was
>>>>> an exception which jumped down the stack?
>>>>>
>>>>
>>>> Because "going out of scope" is really just another name for "is
>>>> popped off the stack." If an error unwinds the stack, then it would
>>>> have to check for the presence of these marked slots on the way down
>>>> instead of just changing the stack top index.
>>>>
>>>
>>> I understand that - but Lua does a longjmp when exceptions are thrown.
>>> Are you saying that the location where the exception is caught (via
>>> setjmp) the stack would be walked up and these functions executed?
>>> Regards
>>>
>>
>> Ugh. That's a good point. I forgot that Lua uses the C stack in
>> addition to its own; I've gotten too accustomed to stackless VMs.
>>
>> There's probably a way to deal with it. I don't know enough about
>> Lua's specifics to suggest an implementation.
>>
>
> I do not think it is possible to implement this without changing the
> way exceptions are managed in Lua. And without correct handling of
> exceptions this feature is meaningless.
>
> FYI here is the Java semantics:
>
> If the try statement has a finally clause, then another block of code
> is executed, no matter whether the try block completes normally or
> abruptly, and no matter whether a catch clause is first given control.
>
> The same is true for other languages that offer this.
>
> Also C++ destructors have the same guarantee of being executed -
> except that there is added complication of unconstructed objects.
>
> In my opinion, the finally approach is better in garbage collected
> languages, but to implement that correctly would mean big changes to
> Lua (i.e. no longjmp). Also the C api would have to offer a way to
> detect exceptions and throw exceptions - in Java the JNI offers these
> capabilities.

I don't think longjmp is a problem, in and of itself. Microsoft used
setjmp/longjmp to implement C++ exception handling and was able to
clean up after itself. They switched to a better implementation later,
yes, but it's still possible. The important bit, I think, is that
setjmp/longjmp isn't part of the exposed Lua API, but instead the Lua
internals are able to set up whatever information they need before the
longjmp call and between the return to setjmp and the invocation of
the panic handler or the resumption of the pcall.

Yeah, we'd be out of luck if the host used setjmp/longjmp for its own
purposes, but I don't think that's any different than now.

/s/ Adam