Re: in-do-end

[Eike Decker <zet23t@...>]

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.
>
>