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

[Hakki Dogusan <hakki@...>]

Hi,

On 5.06.2019 00:27, Lorenzo Donati wrote:
> 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.:
> [snip]
> 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 = ....

What about:

local [scoped, static] resource = ...
[local] mylocalvar = ...
[ongc=myfunction] myresource = ...

Is it ambiguous?


> 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 
> ;-)

--
Regards,
Hakki Dogusan