Re: To-be-closed variables and coroutines

[Viacheslav Usov <via.usov@...>]

On Fri, Jul 31, 2020 at 8:28 PM Egor Skriptunoff
<egor.skriptunoff@gmail.com> wrote:

> We don't need just a "scope exit event".
> The point of why to-be-closed variables exist: we need a "predictable finalizer".
> We need to guarantee that a resource will be closed as fast as possible,
> whatever happened in the code.

Indeed. This seems somehow to have fallen through the cracks.

On November 24th, 2015. Roberto proposed the following syntax:

local <some mark to be invented> name = exp

That was in a thread titled "block-scope finalization" which I started
a few days earlier, with a message that posited that the problem was
"that finalization is non-deterministic, i.e., it is impossible to
predict when it will happen."

In that same message I proposed the following syntax:

block file = io.open('file')

While there are some differences between my original proposal, and
Roberto's original proposal, and ultimately the to-be-closed feature
as we have it now, it seems fairly obvious that this is the same idea:
clean-up when the enclosing block of code is exited.

I reference this particular thread because I think this is when most
of the design decisions were made. Roberto referenced that same
November 24th message as a "technical solution that works" in another
thread in 2018 titled "(not) handling new programming idioms with
grace", whose starter referenced his 2009 thread "state of the Lua
nation on resource cleanup". The "(not) handling..." thread was I
think when the Lua team got serious about implementing the "technical
solution" and that is how we ended up with the current to-be-closed
feature.

It is somewhat ironic that it was Dibyendu Majumdar who did not
believe in 2018 that a "technical solution" existed. Even though he
did not, in my opinion, mention the really problematic aspects that
would make the "technical solution" difficult or impossible, two years
later we still do not have a "technical solution that works period".
Because it is a "technical solution that works sometimes".

What is needed is "that a resource will be closed as fast as possible,
whatever happened in the code", exactly as Egor wrote.

This we do not have.

Cheers,
V.