Philippe:
> 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...)
Still there are newline tokens, but in most positions they are ignorable. This complicates a bit the _javascript_ syntax because the optional presence of newline tokens has to be taken into account. But in some places, their presence is significant (and plays a role like ";"). That's why I wrote they were real tokens and not treated like whitespaces (after discarding all comments, a _javascript_ parser can compact all whitespaces, except in string contents, to a single SPACE token if there are no newlines in them, and to a single NEWLINE token if there's at least one; that SPACE token can be ignored everywhere, but there still remains an optional NEWLINE between most tokens in its syntax and that optional NEWLINE must be treated specially, in each syntaxic rule).
There's still no such rule in Lua: all whitespaces are equal and compactable to a single one, which is discardable everywhere in the actual list of tokens processed by the syntaxic parser, so this greatly simplifies the rules. However I wonder if Lua should not adopt the same policy as _javascript_, because the collapse of two lines which may look as valid separate statements causes unexpected effects with currification (which is just a facility to remove the extra parentheses which can still be used when needed).
(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
