lua-users home
lua-l archive

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


(two weeks ago...)

Peter Hill:
> Regardless, one *should* be able to have:
>     function(a) return a end (123)

Luiz Henrique de Figueiredo:
> This does not work because it requires 2 lookaheads.

It does?

I've been having a more detailed look through "lparser.c" and the change
doesn't seem too hard, nor does it seem to require a second lookahead as far
as I can see.

I'd do it as such...

First we need to handle the expression context, where "function" should
always be a "function() ... end" expression:

Step 1: Move the case that handles TK_FUNCTION from "simpleexp()"  into
"prefixexp()", allowing it to now recognise TK_FUNCTION as well as '(', '%',
and TK_NAME. Ie, "f (3)" and "function (x) ... end (3)" would now be parsed
the same way!

Next we need to handle the statement context, where "function" could start
either a "function f() ... end" statement or a "function() ... end"
expression:

Step 2: Modify the C function "funcstat()"  - just after the TK_FUNCTION
token has been discarded - to include a simple check to see if the next
token is '('. If it's not then continue funcstat() as per normal. If it is
then instead call "body()" to produce a 'prefixexp', then continue as per
"primaryexp()" except that we instead substitute this value for the
'prefixexp' part.

Step 3: To avoid the above action duplicating code we should split the
processing part out of "primaryexp()" into a new function, eg
"primaryextra()", where it can be called by both "primaryexp()" [after
calling "prefixexp()"] and "funcstat()" [after calling "body()"].


Luiz Henrique de Figueiredo (26-Dec-2002):
> It could be made to work, of course. However, instead of trying to cater
> for all possible combinations, we decided that anything can be used for
> calling, but complex things must be inside parentheses. So these work:
>     (function(a) return a end) (123)
>     (987)(123)
> (the second one gives a runtime error, not a compilation error.)
>
> We think this is a simple rule that makes it possible to write complex
> things while not complicating too much the rest of the syntax.

True, however it also requires that the 'functioncall' type of statement can
start with a parenthesis, something which is a current a source of lexical
ambiguity. This change could be a first step on the way to removing that
irritation.

*cheers*
Peter Hill.