Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

[Lorenzo Donati <lorenzodonatibz@...>]

On 04/06/2019 21:27, Patrick Donnelly wrote:
> On Wed, May 29, 2019 at 5:38 PM Luiz Henrique de Figueiredo
> <lhf@tecgraf.puc-rio.br> wrote:
> > Lua 5.4.0 (alpha-rc1) is now available for testing at
> >         http://www.lua.org/work/lua-5.4.0-alpha-rc1.tar.gz
>
> \o/ toclose! (I'll echo that a more Luaish syntax would be preferred
> but I trust the Author's judgement on this.)
>
> I thought I'd also share that another useful local qualifier would be
> <static>. This would be a variable scoped as normal but is initialized
> once when the surrounding closure is created. i.e.:
>
> function foo(...)
>   local <static> cache = {}
> end
>
> is syntactic sugar for:
>
> do
>   local cache = {}
>   function foo(...)
>   end
> end
Wow, that seems like a very nice idea [1].

I use that idiom quite frequently, not only for caches, but also for 
implementation functions, for example:

local fun
do
  local function fun_impl(...)
    -- maybe this function is also recursive
  end
  --[[local]] function fun(...)
    -- ...
      fun_impl(...)
    -- ...
  end
end


This could be abbreviated simply by ([1]):

local function fun(...)
  local <static> fun_impl = function(...)
  end
  -- ...
    fun_impl(...)
  -- ...
end

Note that the outer function is local so in this case the inner <static> 
local would define an upvalue fun_impl which is "private" for the 
function, but the outer function "name" wouldn't need that verbose 
additional local declaration outside a do-end block ([1]).


BTW, I'm still struggling to come up with a better syntax. A keyword 
based approach would be nicer, but it causes ambiguities in the grammar, 
especially when more "attributes" are used (as pointed out by 
Luiz/Roberto somewhere else).

So I try to decide which is better between the proposed syntax:

local <toclose, static, nice, helpful, wonderful> resource = ....

or something like:

local @toclose @static @nice @helpful @wonderful resource = ....

I somewhat prefer the latter, although the @ sigil is a bit ugly. It has 
the advantage that when you visually parse it it is clear that those 
words are attributes, whereas the <...> syntax may become obscure when 
you quickly skim on the code. The angle brackets may be mistaken for 
operators and if the attribute list is long they tend to be swamped by 
the words and commas, etc.

Moreover how would you split that thing if the need arise?
Compare:


local < toclose, static,
  nice, helpful, wonderful > resource = ....

vs.

local @toclose @static
  @nice @helpful @wonderful resource = ....

In the first case the possibility to introduce spaces "inside" the angle 
brackets could be a source of confusion, too (not to mention spaces at 
commas in different coding styles). And maybe also could render the 
grammar ambiguous.

The sigil approach marks in an unequivocal ways the attributes, 
regardless of indentation, spacing, etc..

The more I see it the more I'd prefer the second approach.



Cheers!

-- Lorenzo


[1] too late at night here to think about possible drawbacks or pitfalls ;-)