[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: variable semantics vs value semantics (was Re: Interfacing lua with C)
- From: Lucas Ackerman <ackerman7@...>
- Date: Thu, 16 Jan 2003 17:31:49 -0800
--- In firstname.lastname@example.org, RLake@o... wrote:
> Lucas Ackerman escribió:
> > 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
> > specifies).
> Permit me to disagree. "In C, variables are typed as well as objects" is
> not true. In C, variables are typed (at compile time) and objects are
> bits. In C++ objects have a bit of type, but not all of it, and you can
> still treat them as though they were just bits.
This is true obviously, I was merely commenting that C encourages
thinking of it as "assignment to a value", which naturally depends on
the value's type, and leads to this kind of issue. I code almost
exclusively in C++, and thus failed to make the distinction, but I
rarely if ever subvert the type system (although there's a cool IEEE784
float-to-log-int trick I approve of, since floats are stored as log2
> This is, of course, an endless debate: functional language advocates
> (Schemes, Lispers, Haskellites, etc.) would say that their languages are
> "strongly-typed" because values never lose their type. Cers and
> beg to differ. I think the terminology is probably not helpful.
Naturally, but lending these issues some context is better than not,
especially where Lua differs from C. In Lua, assignment only applies to
variables, never to the values they name.
> In any event, in Lua, variables are just bindings; local variables are
> names of values. If you want a mutable local object, use a local
> assign to its keys. That will do exactly what you want and does not
> any magic. Why would I want to turn the local namespace into a table?
> already create as many local tables as I want. Then I know exactly
> creating overhead and why.
I don't know that I'd want to either, I was just observing that
locals-as-tables (or something similar) is the one piece missing in
Lua's nearly-complete meta-power in the "what is an object" sense.
Global access through tables, tables with function call semantics,
functions with global tables setting, but no "object" that's a true
function/table hybrid. I merely find it an interesting idea.
Incidentally, unless I missed this somewhere, it appears the 5.0b
reference manual doesn't discuss function recursion, and it also appears
a function can't set it's own globals table without being passed a
reference to itself. Giving functions a local "self" reference might be
useful, and make recursive functions faster (skipping the global lookup
or local name passing). I don't know if it could violate the
namespace/sandbox globals-table uses, but it appears harmless enough.