Re: Inline Functions

["Peter Hill" <corwin@...>]

Eero Pajarre:
> (btw. it is pretty cool that "Complete Syntax of Lua"  fits on one page on
> the manual)

I absolutely agree!

<happy rant>
These days there seems to be an illusion that powerful & clear languages
need a really complex syntax =:-O. But that's just not true! And if one
wants to make programming available to the casual user (vs coder) ...
something that I believe will become more-and-more important in the future
(especially now that VCRs etc are being design with operating systems!) ...
then the syntax NEEDS to be simple.
-
Tradionally, end users have always been lumped with some kludgy half-baked
little "macro" language. Historically, Lua was created to redress that
injustice, being a powerful & clean inline language. About time! :-)
</happy rant>


Peter Hill wrote:
> one should be able to write:
>     function (a) print("a="..a) end (123)
> however this doesn't work in Lua4.0. Does it work in Lua5.0?

Eero Pajarre:
> It does not, but
>     ( function (a) print ("a="..a) end ) (123)
> works.
>
> Looking at the "Complete Syntax of Lua" this is just as it should be. You
> need the extra parenthesis in order to convert from "exp" to "prefixexp".

So I see:
    prefixexp ::= var | functioncall | '(' exp ')'

But, at a glance, I can't see why one could not just include "function" in
there as well.
    prefixexp ::= var | function | functioncall | '(' exp ')'

It makes strong sense to have it as a "prefixexp" (what could be more of a
function than "funtion () ... end" itself!) and, as it forms a nicely
wrapped unit, I don't forsee any syntax problems.

I official petiton its addition! *grin*

*cheers*
Peter Hill.

PS:
I notice in the manual that the "free format" of Lua fails in one situation:

    "As an exception to the format-free syntax of Lua, you cannot put a line
     break before the ( in a function call. That restriction avoids some
     ambiguities in the language."

Eg:
    f
    (g)(123)
vs
    f(g)(123)

In essence, it is a situation where an expression doesn't know whether or
not to stop gathering terms.

A similar situation occurs with "return":
    return
    a()
vs
    return a()

Currently "return" is prevented from grabbing extra arguments by wrapping it
in a "do ... end" (something which is *not* shown on the syntax diagram!)
but, with this new syntax ruling, perhaps "return" should simply follow the
same pattern?

Note that not all the arguments would need to be on the one line so long as
a comma was included to show that the arguments continued. Eg:
    return a,
    b,c

*cheers*
Peter Hill.