On Tue, Jun 1, 2021 at 5:58 PM Paul Ducklin wrote: local func = function() ... end
...looks nicer than...
local function func() ... end
It seems there exist two groups of Lua users.
1) First group - users who prefer to emphasize that Lua functions as just regular objects.
The "natural inclination" of 1nd group users is to use the "function" keyword for producing R-values only.
They would be happy with named-functions-syntax completely removed from Lua (despite the small problem with local recursive functions).
2) Second group - users who prefer to write Lua scripts in a way similar to programming in other languages.
The "natural inclination" of 2nd group users is to always see a function's name after the keyword "function".
From their point of view the existing Lua syntax for defining local and global functions is nice.
But when they try to define a function inside an object they are forced to use incongruous "name=function" syntax.
Mixing the two styles in one Lua program is ugly.
I don’t understand the “problem” you are trying to solve
The problem is: the users from 1st and 2nd groups do not have "equal rights".
The former are quite happy in the current Lua, they can always follow their favorite "all-functions-are-anonymous" style.
The latter are unable to always follow their favorite "each-function-is-defined-with-a-name" style.
Please note that most Lua newcomers are in the second group.
But the “conventional” function definition syntax is syntactic sugar to ease beginners into Lua. By the time they are doing advanced things like tables of functions, they *should* be aware of first class functions, and in that case the existing syntax *is* the more natural way to go.
Almost everything that is deeper in Lua is based around first-class functions .. I dont think postponing people having to grasp this is a good thing, once they get beyond the basics.
I agree with the earlier post, its far too easy to mistake { function a() … end } for { function() .. end }, and this is a bad thing imho.
—Tim |
