[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: variable semantics vs value semantics (was Re: Interfacing lua with C)
- From: Lucas Ackerman <ackerman7@...>
- Date: Wed, 15 Jan 2003 17:41:12 -0800
--- In email@example.com, "jimmyp_gr <jimmyp@h...>" <jimmyp@h...>
> > And if you want to make your C-synced variable local in scope then
> > got a problem. In fact, I think it can't be done. :-(
> I don't want my C vars to be local but I want to be able to assign
> values to them the usual way and not interfere with gloabal lua vars.
> I set the "settable" method for the globls table but my method gets
> called only when I assign to my C exported var(a userdata var that
> is).That's what I want but is that normal or am I doing something
> wrong?What if I set the setglobal and getglobal tag methods for my
> userdata C vars?Wouldn't that do the job?
> > In Lua4 there was special treatment for global accesses. As globals
> > stored in a Lua table, in Lua5 this was simplified by allowing
> > that table and using data access metamethods. Local variables,
> however, are
> > still left unhandled.
> Should I switch to Lua5 now or will porting my code to it later be
> easy.I don't want to mess with beta software unless I have to(there
> aren't debian packages for it either I think) but I don't want to
> rewrite the whole thing again later when lua5 is released.
Hi again Dimitris, long time, I'm a Lua fan too :)
I agree that you should probably use Lua5 since you're just starting now.
It's an interesting problem you've run into here, but much of it may be
terminology related (and a C background is rather unhelpful I'm afraid).
Nonetheless I'm happy to break out some CS-fu and contribute. As Peter
pointed out, Lua's untyped nature makes defining type-dependant
operations on variables inconvenient, if not outright impossible. It
might help (as usual) if you could give some context for what sort of
system you're building and what role Lua is to play in it. One way or
another though, you want to access C objects (functions and state)
through Lua. In C, variables are typed as well as objects. This means
that assignment to a variable refers to altering the value in memory
referenced by that name, storing a different value (essentially copying
it there, or doing whatever the object type's assignment operator
In an untyped language like Lua, all (non-trivial) variable values are
pointers, and they refer to the object values (typed by metatables).
Typically all actions happen on the object values which are dereferenced
behind the scenes., but assignment is to variables (pointer values), not
There's a good discussion of this sort of thing in "An Introduction to
Scheme and it's Implimentation", at
The key issue is the distinction between variable semantics and value
semantics. Lua has beautiful meta-capabilities when it comes to value
semantics, but it's variable semantics are more fixed. The globals
table feature does add some flexibility (if you wanted, you could check
the existing value of a global variable and do something special on
assignment if it is already pointing to one of your C objects), but
locals aren't yet addressed.
You say "I want to be able to assign values to them (C vars) ..." when
what you mean is that you want to be able to treat assignment to Lua
variables referencing C-object wrappers (tables or userdata) as C-style
assignment, altering the referred object's memory instead of making the
variable refer to a different object. Simple answer: you can't. Using
extra functions to do the work is trivial of course, but won't be
automatic and clean like an assignment.
That said, I'm going to throw out another idea here, useful or not.
We've seen some interesting tricks on lua-l with closures to get object
behavours with them, but there isn't a way to intercept a block's local
variables as with table elements (not without assigning a new globals
table to a function instead). There's really a big grey area when it
comes to "how do we define what an object is?", relating to state,
behavior, etc, and Lua's variables (*not* values) are one of the places
where the rules are constrained. The variable assignment rules are fixed.
Off-hand, there's an interesting progression (listed in no particular
order here) in Lua's flexibility:
Global accesses are now done through regular tables.
Tables can have function-call semantics.
Functions can have their "global" table set.
... and around and around we go!
Locals are the one limited piece - you can't redefine what it means to
access a local (or assign to a fundamental variable value, which could
be in a table for example). I could certainly imagine Lua being
extended to treat all variable accesses uniformly, with essentially a
real table for locals. The obvious reason NOT to do this is
performance. Simple locals are FAST. However, an alternative might be
to add new variable value types to Lua: assignment-marshalled values
(one for tables and one for userdata). They would be just like any
other variable, but delegate assignment handling to it referenced
object. Whether this will happen is another matter completely, but it
doesn't seem likely unless people feel it would really simplify things.