Re: variable semantics vs value semantics (was Re: Interfacing luawith C)

["Peter Hill" <corwin@...>]

Lucas Ackerman:
> 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).

RLake:
> 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.

Lucas Ackerman:
> 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 disagree. In C "lvalues" (ie, variables) have a type but *so do* "rvalues"
(ie, objects). Though rvalues do have a short lifetime (such that they may
only exist on the stack) they are objects independent from variables,
carrying their own type.

This can also happen in a similar (artifically constructed) sense in Lua,
though in Lua there is of course no gain in speed or memory usage in doing
so. For example, I can create a variable "xyzzy" that is "strongly typed" as
a "number" as follows:

    -- Define a table where number-typed variables may live.
    nvars = {}

    -- Create a metatable (destined to belong to _G).
    m = {}

    -- Any attempts to store data to a "number" variable
    -- requires type coersion.
    function m.__newindex(t,k,v)
      local z = nvars[k]
      if z then nvars[k] = tonumber(v) else rawset(t,k,v) end
    end

    function m.__index(t,k)
      local z = nvars[k]
      return z or rawget(t,k)
    end

    setmetatable(_G, m)

    -- Define "xyzzy" as a number-typed variable
    nvars.xyzzy = 0

    -- Store a numeric string into the global "xyzzy".
    -- The assignment will coerse the string into a numeric before
    -- storing it in the "numeric only" variable "xyzzy".
    xyzzy = "123"
    print( type(xyzzy) )

As usual, this will only work with globals (not locals) for the reason
currently under discussion. :-(


RLake:
> 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.

The string "123" assigned (in my example above) to the 'typed'-variable
xyzzy lost its type(!) which shows that Lua's metamethod power pulls it out
of the Scheme etc category. :-O


RLake:
> I think the terminology is probably not helpful.

Lucas Ackerman:
> 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.


RLake:
> In any event, in Lua, variables are just bindings; local variables are
> names of values.

Huh? They're not the 'names of values'... they are the (compile time) names
of runtime variables, which can themselves hold many different values over
time.


RLake:
> 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.

Presumably for "clarity" (in the programmer's eyes) of some concept. Ie,
some people like things verbose-and-visible, while others like things
implicit-and-clean. Both grant a certain type of clarity.

Lucas Ackerman:
> 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.

Agreed. The metamethod-affecting-globals adds an extra power to globals that
breaks some of the symmetry with local variables, which can't (currently)
match its power. Whether that symmetry should be restored (ie, is the fix
both easy and useful enough) I don't know. It would depend somewhat on
the potential usage of such a feature, and that is something which up until
now has not been considered.

*cheers*
Peter Hill.