lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Tue, Nov 24, 2015 at 3:54 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> On 24 November 2015 at 20:45, 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

Lua already does that when closing upvalues, in luaF_close. This
proposal would probably be implemented by expanding luaF_close's
purpose to also call the __close metamethod on these new types of
locals. Fortunately a lot of the work for closing upvalues overlaps
here.

-- 
Patrick Donnelly