[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Suggestion for local tuples
- From: Dirk Laurie <dirk.laurie@...>
- Date: Thu, 31 Jan 2013 16:11:04 +0200
Consider the following code.
local x_1, x_2, x_3, x_4 = ...
-- followed by numerous references to x_1, x_2, x_3, x_4
It can be syntax-sugared:
tuple x = ...
-- followed by numerous references to x, x, x, x
Not merely sugar: one can now write x[i] without giving the value
of i as a constant.
It's reminiscent of Lua 4.0's 'arg', now defunct. But 'arg'
was a table, 'tuple' is a block of consecutive local variables.
You can write to items in it and there is no expensive table access.
A variable argument list is not the only application.
tuple x = 1,3,2,4,7,8
Later, `return x` will return the current values of that
A tuple could be the final parameter of a function call, particularly
to `select`. As in the case of `select`, no new objects will be constructed:
y = select(3,x)
y and x will refer to the same local variable.
Some very fast code, not involving any table accesses, everything is
on the stack, can be written this way.
Semantics of x==y when at least one of the two names refers to
a tuple could be actual term-by-term equality. This is not over-expensive
since tuples can't be very large: they eat into the same cake that feeds
I miss one baselib function to go with `select`, called maybe `head`,
that will make life with tuples more rewarding. It returns exactly
those parameters _not_ returned by select. Its code is very similar
to `select`, except that we don't need the possibility of `#`.
return n - i;
is to be replaced by
To summarize: a Lua tuple would simply be a block of consecutive
local variables, of known size, and (unlike a Python tuple) having