Re: future of annotations in Lua?

["szbnwer@..." <szbnwer@...>]

hi there! :)

Philippe:

[not so important part]

> Note also that Javascript has similar issues, but it does not require ";" only because it differenciates whitespaces (those that include a newline not part of a comment from other whitespaces); you cannot safely remove all newlines in Javascript and merge all whitespaces to a single space, without adding a few ";" where needed. So Javascript's parser defines the newline token!

thats even more complicated than that. if u write
```
x=
3
```
then it will work, cuz there is an unfinished expression (and its
maybe even more complicated than this ... once ive seen all the rules,
it was a bit twisted...)
(off topic, but not, cuz parsing is related to the new syntax.)

[not so important part]

> The "expression statements" in Lua currently only allow expressions that are simple function calls (with the form "a(b...)" or "a b..." if it is currified), but it currently forbids expressions using unary or binary operators, like "a + b" or "(a + b)" or "a[b]", as valid statements, even if they are intrinsicly a function call, to "__add(a, b)" and "__getindex(a, b)" in these examples.

> And I see no fundamental problem in extending "expressions statements" in Lua to any valid Lua expression (even if this has no effect such as using a simple number or string, or "-1" with the unary operator, or "1+2" with a binary operator). It does not change the syntax complexity at all, but just simplifies it with no additional cost and without changing any existing semantics or runtime and debugging behavior.

thats kinda similar to one of my greatest wishes, that is writing `a
and b(c) or d(e)` (as a freestanding statement) instead of `local _=a
and b(c) or d(e)` that is really an ugly hack (i mean `local _=` :D )
(((the other greatest is `{}:x()`)))

the main reason ive got against both of these is the ambiguity in cases like
```
local a, b, c=0
x and y() or z()
```
where b will become something evil, but we already need the semicolons
here and there. otherwise i dare to believe that lua folks love the
`and`+`or` "hacks" and it would be nice to have these instead of
writing `if x then y() else z() end` in simple cases and i think the
alternative way is even faster to interpret mentally and helps against
global warming (never mind, im crazy) cuz saves some cpu cycles :D
(mayb not, but i just want to believe it like so. :D )

btw i think the best is to group locals only where it makes sense, like:
```
local a, b, c -- uninitialized, no harm can happen, cuz no assignment
returnRandomAmountOfVals()
local x, y, z=1, 2, 3 -- all 3 vars are taken, no accidents
returnRandomAmountOfVals()
```
and anyway we can already mess with assignments with any function calls...
(off topic, but not, cuz i think that the same reasoning applies against them)



Egor:
> @attributename              -- for attributes without arguments
   @(attributename arguments)  -- for attributes with arguments

+1, but a big ONE!
currently this is the most friendly for my eyes