Oh sorry, I misunderstood what you were suggesting. So you mean that: <return values = > foo(function() <block> end) could also be written as <return values = > foo function() <block> endwhere foo is a function that will receive the return values of the execution of <block>. I guess that 'function()' and 'end' make a set of valid delimiters, maybe it can be done unambiguously. But it would reduce the parser's ability to detect syntax errors by a considerable amount.
The benefit of a = math.ceil function() return math.random() * 10 end over a = math.ceil(function() return math.random() * 10 end)is questionable (hardly less characters, debatable whether it is more or less readable), and doesn't really seem worth the cost of losing a great deal of syntax error detection IMHO. On the other hand, if we had a briefer syntax for anonymous lambdas.... :-)
On Jan 20, 2010, at 11:56 PM, Eike Decker wrote:
Calling a function by passing a function variable would not work that wayfoo print Just as well as this doesn't work as well (for good reason): --- str,tab = "str",{} print str print tab --- even though print "" print {} is working. The very same would go for --- print function () end --- If the definition of the language would state, that a function call is not only triggered by string or table definition but also by a function definition, then this should not be a problem. The only problem that I can see is a "psychological" one, which is that the function call is not as clear as with a string or a table definition because the keyword "function" is a mere word where as the string definition starts with ", ' or [[ and a table definition starts with {. That's quite a difference. It could also unintendedly cause problems where someone wants to write print = function () but forgets the equation character. But that could happen with a table or string definition as well, causing most likely an "attempt to call a nil value" error message. Greetings, Eike 2010年1月21日 Graham Wakefield <wakefield@mat.ucsb.edu>:Interesting - I think it would be nice, if it could be done unambiguously,and I would use it. But I bet many would not (terseness reducing comprehensibility etc.) How about this example: print print print printis this print with 3 arguments, 3 nested calls to print, or two prints withone argument each? i.e.: 1. print(print, print, print)2. print(print) print(print) -- unambiguously: print print; print print;3. print(print(print(print))) I think the 3rd interpretation is the right one.The 1st could be eliminated by restricting to only one argument, just likestrings and tables.The 2nd could be eliminated if the parser can eagerly consume raw functionarguments (I don't know how the parser is written). That suggests a further problem: print foofoo might be a function, or it might be a number, or userdata, or any other type, which can only be known at run-time, not parse-time. The change wouldtherefore need to allow any variable to be a single un-parenthesized function argument. Still worse: foo printIs this a function call? Or a syntax error? Only the type of foo can say.On Jan 17, 2010, at 3:59 AM, Eike Decker wrote:I think that's the issue: consider the two lines f = avalue function g(x) ... endIf 'function' could appear directly as a function argument, then thesestatements would not work as expected. steve d.That wouldn't be a problem since "function g(x)" is a statement to assign a function that is currently defined to the global value "g", whereas "function (x)...end" is no valid statement at all, unless it is being a part of an argument or a value to be assigned to a variable.