[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Inline Functions
- From: "Peter Hill" <corwin@...>
- Date: Sun, 12 Jan 2003 01:31:12 -0000
(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.