Re: in-do-end

[Graham Wakefield <wakefield@...>]

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.