I propose to extend te syntax of table constructors like
this:
{
--
starts a new local context (closure)
[:
ref0 = 'k1'] = : ref1 = v1, --
['k1'] = v1 and set external ref0 = 'k1'
[:
ref2] =
v2, -- [1] =
v2 and set local ref2 = 1
[:local ref3]
=
v3, -- [2] = v3
and set local ref3 = 2
[:local ref4 = 'k2'] =
:local ref5 = v4, -- ['k2'] = v4 and set
local ref4 = 'k2', local ref5 =
v4
[:local ref6 = 'k3'] =
: ref7 = v5, -- ['k3'] = v5
and set local ref6 = 'k2', external ref7 =
v5
k4 =
ref0, -- ['k4'] =
'k1'
[
'k5'] =
ref2, -- ['k5'] = v2
ref1, -- [3]
= v1
}
--
close the local context
The idea is to allow constructors to use cyclic references by
allowing to define "tracking" variables keeping the
key (eventually the implicit numeric key) and the value
assigned to a key; these variables can be defined in local scope
(the scope is a closure, the local context of the table constructor
itself) or in external scope (any enclosing scope, eventually
outside any table constructor, or in another enclosing table
constructor).
The syntax for keys is not changed, it still uses the [] to
enclose an _expression_.
However the _expression_ allowed in a key (between []) or in a
value (after the = if there's a key specified before) is extented
by allowing one of these form to set variables:
:local variable, (only for key expressions), or
:local variable = _expression_, or
:variable, (only for key expressions), or
:variable = _expression_, or
_expression_, or
* The first two forms define the variable in the current
local scope (it creates a new variable in the local context, like
with function closures, or local contexts of enuneration variables
in "for", hiding any external variable defined with the same
name).
* The last two forms can use any lvalue _expression_: if the
external context does not have this variable defined, it will
create the variable in the external context, otherwise it will
replace its current value.
This syntax extension is simple to parse (no complex
look-ahead or backtracking), it just starts with a leading ":"
before the local or external variable, the '=' sign (optional if
there's no _expression_ and permitted only in the key part, required
in the value part) and the _expression_ (optional only in the key
part because it implies an implicit numeric key)
You may prefer to change the syntax distinguishing the
assignment of local and external variables (":local variable"
versus ":variable"). For example:
- ":variable" for the a local variable (must be a "name" or
"[_expression_]"), or
- "?variable" for setting an external variable (which can be
any lvalue _expression_)
In all cases, the locality is limited to the scope of the
table constructor, it is permitted to reassign the same variable in
the same local or external scope, like in standard Lua assignment
instructions, or in standard declarations of local variables in
functional blocks.
No limit is set on the types of values that these variables can
hold (only the nil value is invalid as the key of a table entry,
but not invalid as the value of a table entry).
This allows to entirely serialize any table (including
cyclic/recursive ones) in pure data-only format (the data-only
format is independant of the context where it is used if all
variables set inside the main table constructor are defined locally
in the main table constructor (but external, non-local, variables
can still be used in a sub-table).
It is even possible to serialize tables containing code (i.e.
function blocks), with their defined lamda expressions, possibly
even coroutines (only functions that are defined as external
C-functions cannot be serialized with their code, they can only be
referenced by their binding name; C functions and coroutines are
most probably excluded from pure data-only table constructors, but
lambda functions may be permitted if the code inside them does not
any use external references to variables not in local scope of the
main serialized table and does not use external C-functions or some
restricted functions of the Lua library; some functions of the Lua
library may still be allowed, including pcall(), that can locally
handle exceptions)
