lua-users home
lua-l archive

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

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> end
where 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 way 

foo 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 print
is this print with 3 arguments, 3 nested calls to print, or two prints with 
one 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 like 
strings and tables.
The 2nd could be eliminated if the parser can eagerly consume raw function 
arguments (I don't know how the parser is written).

That suggests a further problem:

print foo
foo 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 would 
therefore need to allow any variable to be a single un-parenthesized
function argument.

Still worse:

foo print
Is 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)
...
end
If 'function' could appear directly as a function argument, then these 
statements 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.