[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua has reached a local optimum
- From: "szbnwer@..." <szbnwer@...>
- Date: Sat, 7 Jul 2018 15:01:08 +0000
Gé Weijers:
the newline stuff is a bit overcomplicated in javascript, therefore i
always use them there, except at the end of scopes, so where are curly
braces. in lua, i think ive never needed any. mostly id like to use
this for ad-hoc strings with :rep, :sub, :gsub and whatever. generally
(in assignment, func argument and concat) they would be totally
innocent and i just feel them redundant. like i cant even find a case
for trouble, an ad-hoc string/table must be used immediately, and in a
function call id write `f(' ':rep(8))`, otherwise its meaning for my
mind and the interpreter `(f' '):rep(5)` (if im right). a semicolon is
fine, and it woulndt complicate nothing as its already the case for
current lua that it is required sometimes... writing stuffs the same
way as currently would still be possible, so compatibility remains.
whats the difference between `a=b+c (' '):rep(8)` and `a=b+c '
':rep(8)`? if `c` is callable then it can be `c(' ')` and `c' '` just
as well...
`f((a or b); (c))` - what?! :D i cant even see the purpose... maybe
for ` f((a or b), c)` but thats a different beast and legit anyhow...
anyway what about `f() or g()` or `option and f()` without using the
value of the expression? i think its nice with lazy evaluation, and
could produce shorter codes with less `if`s.
probably this could take a bit of carefulness:
```
local a, b, c=1, 2 -- `c` probably wont be just an undefined local
f() or g()
--here can come any kinda trouble related to `c`
```
so it can be either `... 1, 2;` or `;f() ...`, but id prefer the 1st,
as that is the dangerous portion, so copypaste will remain safe.
i believe the 1st proposal is in nice harmony with optional braces,
and both match with the mindset of lua users, who already know that
sometimes semicolons are required.
so what else is against these?!
the 3rd proposal with trimmed err messages also wouldnt break nothing.
who never met with it, they didnt prepare nothing related to
`...longpath`, who did, they had to check for `...` and the "didnt
find" branch will handle the new way (if it will be accepted :D ).
thx for your time and all! :)