Re: future of annotations in Lua?

[Lorenzo Donati <lorenzodonatibz@...>]

On 10/06/2019 18:31, Coda Highland wrote:
> On Mon, Jun 10, 2019 at 10:19 AM szbnwer@gmail.com <szbnwer@gmail.com>
> wrote:
>
> > Roberto:
> > > Maybe I missed the answer, but repeating Dibyendu's question: How
> > to reconcile a syntax that prefixes an entire local statement with
> > per-variable annotations?
> >
> > whats wrong with `local <const> a, b, <const> c, d`? do u mean that
> > `local <const> a, b, c, d` means by default that a-d are all
> > constants, so actually an opt-out would be needed for those that
> > shouldnt be constants?
> >
> > if i understood u correctly, then i think the interpretation of my 2nd
> > expression above just shouldnt make b-d constants; or i could think
> > about (with the `@` notation) this for making all vars constants:
> > `local @@const a, b, c, d` - so doubling the at symbol would extend
> > the range of the const from the 1st variable to all of them. this way
> > both needs are covered, and its really a visible thing to prevent
> > messing around stuffs like `a.b()` vs `a:b()` that took away some
> > happy time from all of us here not even once. :D (no offense for `:`,
> > basically im fine with it. :) )
> Your thought there is fine. The question was about the suggestion to put
> the annotation BEFORE the "local" keyword. That syntax would essentially
> make it impossible to put both annotated and not-annotated variable
> declarations in the same statement; it would be all or nothing.

Mmmh, /IF/ annotations are not meant (even in the future) to annotate 
objects, but just variable declarations, I'm not sure it is a good idea 
to allow mixing annotations in the same statement.

I fear that it could be source of errors like in C with pointer 
declarations:

int *a, b, c;	// b and c are NOT pointers, but inexpert people read:

int* a, b, c;	// where int* is interpreted as the type for a, b and c

BTW, writing `int* a` instad of `int *a` seems to be adviced in "modern 
C", together with avoiding multiple declarations per statement.

In Lua there is a catch, however: multiple assignment. So if I want to 
store just one result from a call in a const variable I must have the 
ability to

local a, <const> b , c = f(...)

So, meh, I assume you have to live with the risk.

That's another reason I don't like that syntax (and I'd prefer @const, 
with @ not separable from `const`). In fact this would be a mess to /read/:

local a, < const > b, c, < const, helpful > h, < toclose > z = f(...)

(imagine longer names for realistically complex statement where such 
syntax would be applied)

Spaces together with <> "operators", especially when multiple attributes 
will be supported will be extremely confusing when reading/debugging code.

Compare:


local a, @const b, c, @const @toclose h, @toclose z = f(...)


So the "sigil" @ would also replace the need for commas between multiple 
annotations. So an annotation list would be a space-separated sequence 
of identifiers beginning with @, with no intervening token inbetween.

Neither syntax is beautiful, IMO, but this latter is the least of the 
two evil, IMHO. A nicer syntax would be to introduce new keywords (At 
least for "const"), but this has other drawbacks and still doesn't 
provide a general syntax for the future "annotation list" thing.

BTW, I also agree with someone else in this discussion about "scoped" 
being a better substitute for "toclose". The problem is the __close 
metametod, which will not match the attribute (rename it to __scope is 
misleading, maybe __scope_handler, longer, but MUCH more readable).

> I think this particular issue is a good reason why the annotation should
> prefix the specific declaration being annotated instead of having it prefix
> the statement. Other languages just don't allow you to mix them in a single
> statement, but if that's a desirable feature in Lua then I don't think it's
> worth bikeshedding over the positioning.
>
> /s/ Adam