lua-users home
lua-l archive

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


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