lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

--- In, 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.