Re: variable semantics vs value semantics (was Re: Interfacing lua with C)

[Lucas Ackerman <ackerman7@...>]

--- In lua-l@yahoogroups.com, 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 
just
> 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 
approximations :).

> 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 
Fortranians
> 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 
table and
> assign to its keys. That will do exactly what you want and does not 
involve
> any magic. Why would I want to turn the local namespace into a table? 
I can
> already create as many local tables as I want. Then I know exactly 
when I'm
> 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.

-Lucas