lua-users home
lua-l archive

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

On 31/05/2020 10:26, Axel Kittenberger wrote:

Hello, recently I worked again with lualatex* and again one of my biggest
gripes was Lua not allow trailing commas on function calls.

tex.write(
   '\\begintable{}', value, 'bla',
   '\\endtable{}',
);

results in: unexpected symbol near ')'

I know I made this case before (including patch) but I want to give it
another shot.

Note:
* these argument lists can get pretty long, and added new stuff or removed
stuff quickly while coding
* { } objects allow trailing commas, because "created automatically". I
don't see why sometimes you wouldn't create code that also includes calls
with arbitrary arguments automatically (I certainly have)
* I know you could work around this (and thats what I'm doing now) by
having this functions take one table as argument only. Like mycall{ 'foo',
'bar', }. However despite jumping to some hoops in the callee. It's not
really understandable for others editing my code, why some calls have ()
and some have {}.
* there just is no implicit "nil", neither in the call nor in the object.
* It's just one line of code that needs changing for this syntax to valid.
It would make live easier for some. I don't see any harm in it (except the
argument back then, that some people brought up alternative ideas for
"implicit nils" that didn't happen anyway, and would have been in conflict)

Please give it another thought. Yes, there are use cases out there where
this would be a small quality of live improvement.



I support your request.
Although I rarely generate code containing calls with arbitrary arguments, I often write code which requires passing an arbitrary number of args, and end up writing something like: 


funcname(
 arg1, -- explanation 1
 arg2, -- explanation 2
 arg3, -- explanation 3
...
 argN -- explanation N
)

And those args gets modified all the time and also shuffled around.
It happens regularly to me to forget to adjust that last comma, and anyway it's a pain in the butt, since those args sometimes are multiline strings or big table ctors.
Note that this isn't "regular" Lua code, but usually DSL files parsed by "real" Lua code, so if someone argues this is bad Lua formatting style, I prevent that objection.
As for the "counterproposals" you mention, I hope Lua would NEVER have implicit nils in calls, since something like: 

funcname(1,2,,,3,,"hello",,)
is ugly and error prone. Although it could seem easier to do that instead of explicitly typing nils, it will come back and haunt you, I grant you! Go count those commas! Add a couple more and they are like Snowwhite's 7 dwarves (as we sometimes say in Italy): when you try to name them all, you always forget one (who is never the same, even if you try twice in a row!). :-D
And yes, I used languages with implicit nils and they are a continuous source of hard to spot errors (e.g. AutoHotkey for automating tasks in Windows).
Anyway, I can't say if there is some caveat to modify the syntax the way you ask (could it break something in some corner case?), but I hope the reason NOT to allow optional trailing commas is that it precludes implicit nils!
Moreover, as you note, it would be consistent with table ctors and makes the syntax a little bit more "regular". 


- Axel

* In this recent case I wrote a small Lua wrapper around tikz, since I
prefer to have a "real" programming language when doing geometric
calculations, instead of jumping through the \pgfmathresult hoops. And yes
I want it to be Lua, since that's integrated in lualatex alrady. Anyway, my
wrapper takes for example "paths" and "drawing options" yes thats a lot of
arguments and yes the non allowed trailing commas is either a constant
nuisance <https://dict.leo.org/german-english/nuisance>, or unnecessary
bloat by taking single argument tables instead with for others confusing ()
and {} differentiation.
I perfectly agree! I also have concocted some wrappers to generate LaTeX stuff (quite frequently indeed), and the "last-arg-no-comma" thing has been quite a recurring annoyance.
BTW, switching to {} syntax could have quite a performance hit if you are calling that function lots of time in a tight loop. And then you need to access the args as t[1], t[2], etc., which hampers readability, unless you assign those to locals, and that is just additional clutter. 


My 2 eurocent, anyway!

Cheers!

-- Lorenzo