Lua 5.4 alpha: (yet more) toclose feedback

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua 5.4 alpha: (yet more) toclose feedback

Matthew Wild
I have two issues with the current "toclose" implementation.

Firstly, it had initially passed me by that <toclose> is only valid in
single-variable local declarations. I'm curious what the rationale for
this is, given the widespread use of multiple-return functions,
including within 'toclose's primary usage example, io.open().

The 'val, err' return pattern is everywhere, including Lua's own
standard library. What is it envisioned that idiomatic file-opening
code would look like?

```
local _f, err = io.open("file.txt")
local <toclose> f = _f
```

?

Secondly, I'm going to bring up the can of worms that is... naming. I
personally don't care too much what it is called, but I feel that in
some cases naming in things like programming languages can be
important to help people grasp concepts and semantics.

Here is the list of names I've seen proposed so far on this list:

<toclose>
<autoclose>
<scoped>
<cleanup>
<onexit>
<finalize>
<resource>
<unwind>
<bind> (or <bound>)

Of this list I strongly prefer the last.

Here are some reasons against toclose:

  1) 'toclose' borrows a name from open/close, which is common
file/network oriented terminology, but it isn't always going to be
about opening/closing things (using the functionality for locking has
come up multiple times, for example).

  2) It is strange to "close" something twice, but this is the
behaviour if the same value is assigned to multiple locals using this
feature (I believe that behaviour is absolutely correct, but not
intuitive based on the naming).

  3) It feels like multiple words were used ("to close") just because
it was hard to find an accurate single word that explains what the
feature does succinctly. It also requires the manual getting even more
awkward than the syntax, growing it to the phrase "to-be-closed" in
most places.

Now some arguments in favour of 'bind':

  1) unlike "toclose", it also implies "const" - the word "bind" means
to semi-permanently join two things together (in this case the
variable and the value, or the resource represented by that value)

  2) while "open" and "closed" is a state of an object/resource and
generally it doesn't make sense to "close" something twice, there is
no reason a value cannot be bound to multiple variables, and therefore
no reason an __unbind metamethod couldn't be sensibly called twice

  3) it feels very natural (to a native English speaker at least) to
discuss 'bound variables', far more than the awkward hyphenated phrase
"to-be-closed" all the time.

  4) "bind" is 4 characters vs. 7 characters in "toclose" (so less
typing, less visual noise when reading code, less reason for people to
dislike the angle brackets)

These are the only two things that I feel are problematic with the
current implementation. The syntax discussions are interesting, but
most proposals have their drawbacks (I'm also not saying the current
syntax is perfect, but it does the job).

Regards,
Matthew

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 alpha: (yet more) toclose feedback

Roberto Ierusalimschy
> Firstly, it had initially passed me by that <toclose> is only valid in
> single-variable local declarations. I'm curious what the rationale for
> this is, given the widespread use of multiple-return functions,
> including within 'toclose's primary usage example, io.open().

No specific rationale, it was just easier to implement. We will change
that.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 alpha: (yet more) toclose feedback

Soni "They/Them" L.


On 2019-06-23 5:07 p.m., Roberto Ierusalimschy wrote:

> > Firstly, it had initially passed me by that <toclose> is only valid in
> > single-variable local declarations. I'm curious what the rationale for
> > this is, given the widespread use of multiple-return functions,
> > including within 'toclose's primary usage example, io.open().
>
> No specific rationale, it was just easier to implement. We will change
> that.
>
> -- Roberto
>

I do wonder how <toclose> handles nil, and why it's a bug for <toclose>
to close a non-closeable value.

consider:

local <toclose> f, err = io.open(foo)
if not f then return nil, err end -- error: attempt to close
non-closeable value

v
Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 alpha: (yet more) toclose feedback

v
On Sun, 2019-06-23 at 17:13 -0300, Soni "They/Them" L. wrote:
> I do wonder how <toclose> handles nil, and why it's a bug for
> <toclose>
> to close a non-closeable value.
>
> consider:
>
> local <toclose> f, err = io.open(foo)
> if not f then return nil, err end -- error: attempt to close
> non-closeable value

https://www.lua.org/work/doc/manual.html#3.3.8:
> If the value is nil, it is ignored; otherwise, if it does not have a
__close metamethod, an error is raised.

I think that in your case error is raised because `err` is marked at
toclose as well and it is a string (can't say for sure).
I have to admit that it's really inconvenient for this use case.

--
v <[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 alpha: (yet more) toclose feedback

Soni "They/Them" L.


On 2019-06-23 5:20 p.m., v wrote:

> On Sun, 2019-06-23 at 17:13 -0300, Soni "They/Them" L. wrote:
> > I do wonder how <toclose> handles nil, and why it's a bug for
> > <toclose>
> > to close a non-closeable value.
> >
> > consider:
> >
> > local <toclose> f, err = io.open(foo)
> > if not f then return nil, err end -- error: attempt to close
> > non-closeable value
>
> https://www.lua.org/work/doc/manual.html#3.3.8:
> > If the value is nil, it is ignored; otherwise, if it does not have a
> __close metamethod, an error is raised.
>
> I think that in your case error is raised because `err` is marked at
> toclose as well and it is a string (can't say for sure).
> I have to admit that it's really inconvenient for this use case.
>

ooh. I see. I didn't realize that. (the code was hypothetical, and so
was the error, sorry.)

still wish toclose was mutable (or at least nil-able) tho. for
cancelling the closing.

Reply | Threaded
Open this post in threaded view
|

Re: Lua 5.4 alpha: (yet more) toclose feedback

Coda Highland


On Sun, Jun 23, 2019 at 3:54 PM Soni "They/Them" L. <[hidden email]> wrote:


On 2019-06-23 5:20 p.m., v wrote:
> On Sun, 2019-06-23 at 17:13 -0300, Soni "They/Them" L. wrote:
> > I do wonder how <toclose> handles nil, and why it's a bug for
> > <toclose>
> > to close a non-closeable value.
> >
> > consider:
> >
> > local <toclose> f, err = io.open(foo)
> > if not f then return nil, err end -- error: attempt to close
> > non-closeable value
>
> https://www.lua.org/work/doc/manual.html#3.3.8:
> > If the value is nil, it is ignored; otherwise, if it does not have a
> __close metamethod, an error is raised.
>
> I think that in your case error is raised because `err` is marked at
> toclose as well and it is a string (can't say for sure).
> I have to admit that it's really inconvenient for this use case.
>

ooh. I see. I didn't realize that. (the code was hypothetical, and so
was the error, sorry.)

still wish toclose was mutable (or at least nil-able) tho. for
cancelling the closing.

A reference wrapper would be trivial to write. Depending on your use case, having the object itself know whether or not it should be closed (perhaps by invoking a method on it or setting a value) is another option.

/s/ Adam