Lambda the Ultimate

Here is the for statement. ;)

The Lua wiki has some interesting content, such as LuaAddons.

As of December, there is a Lua book out.

it seems to me that the language could be made much cleaner by treating multiple return values as tables; parameter lists for functions as tables (which would give named params for free); and some syntax to flatten nested tables.

also, while it supports first class functions and closures, there's no way to structurally recurse over a table's contents - no car/cdr for tables. adding that seems like much more major surgery and perhaps you'd end up with scheme as a result ;o)

on the other hand, i suspect i could make lua behave in the way i describe above... and i wonder whether anyone has translated clos into lua. it strikes me as not being that difficult (but i'm no expert). i noticed support for optimized multiple inheritance in someone's add-on package, but not for multiple dispatch.

there's no way to structurally recurse over a table's contents There's for i in table, that's enough.

it was in the context of using tables for return values and parameter lists. if you wanted to call one function with argumnets that were the results of several othes, then it might be useful.

that's enough

i understand that all you really need are functions and the empty set.

(btw, when i said i thought i could implement what i suggested, i meant within lua, using the metatable stuff. my point was that it's sufficiently flexible that you can mould it to your needs.)

I actually prefer the Lua way of doing multiple return values to just returning a table. It is less bulky to work with as it is.

Lua isn't Scheme. It is designed to make immediate sense to non-programmers, and to those who haven't come across the Scheme paradigm. It might not be a perfect, or even a "good" language, but is very suited for its niche- which from my perspective is that of a simple, small, fast, dynamic, and embeddable language.

There are plently of other good languages if you want what Lua is not.

these results don't make much sense to me:

> function zero_two ()
>> return 1,2
>> end
> zero_two()
> print (zero_two())
1       2
> print ((zero_two()))
1
> function one_one (x)
>> return 2 * x
>> end
> print (one_one(zero_two()))
2
> function two_two (x,y)
>> return 2*x, 3*y
>> end
> print (two_two(zero_two()))
2       6
> print (two_two((zero_two())))
stdin:2: attempt to perform arithmetic on local `y' (a nil value)
stack traceback:
        stdin:2: in function `two_two'
        stdin:1: in main chunk
        [C]: ?
> function three_three (x, y, z)
>> return 2*x, 3*y, 4*z
>> end
> print (three_three(zero_two()))
stdin:2: attempt to perform arithmetic on local `z' (a nil value)
stack traceback:
        stdin:2: in function `three_three'
        stdin:1: in main chunk
        [C]: ?
> print (three_three(0,zero_two()))
0       3       8
> print (three_three(zero_two(),0))
stdin:2: attempt to perform arithmetic on local `z' (a nil value)
stack traceback:
        stdin:2: in function `three_three'
        stdin:1: in main chunk
        [C]: ?

the first is that an extra set of parentheses drops all but one return value.

the second is that multiple return values are treated as multiple only at the end of an argument list (see the last example). that stinks of implementation efficiency coming before regular semantics.

and the possible third (depending on your personal ethics, i guess) is that multiple values are dropped silently and extra nulls inserted silently.

i do agree that being able to treat tables as lists is taking things too far towards scheme - i hinted at that in my own post - but i don't think there's anything particularly un-natural about recursion to non-programmers.

ps:

> function zero_what ()
>> return {1,2}
>> end
> print (two_two(zero_what()))
stdin:2: attempt to perform arithmetic on local `x' (a table value)
stack traceback:
        stdin:2: in function `two_two'
        stdin:1: in main chunk
[C]: ?

would that really be more complicated if it worked?