[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: The real problem with vectors and Lua
- From: RLake@...
- Date: Mon, 30 Jun 2003 09:52:50 -0500
Dylan Cuthbert escribió (hace tiempo):
> I don't mind position:set_x( 10 ), but this is getting away from my
> my problem is the fact that these vectors are classed as *tables* in
> need them classed as atomic objects like strings. There is another mail
> this thread from Adam D Moss and he refers to "all hell breaking loose",
> that is a serious problem for a language that is being bandied about as
> scripting environment.
The problem is not that the vectors are classed as tables. As various
people have pointed out, you can change the behaviour of a table however
you want to.
The problem is that you want mutable objects and you *also* want to be
able to mutate them. That's incompatible.
In other words, if you never actually did:
vector.x = 10
But always did
newvector = vector:set_x(10)
or some such (I proposed a few alternative syntaxes for your
consideration), then the problem disappears.
In other words, if vector is an atomic, immutable object, then
vector.x = 10
is not a meaningful construct. It would be the same as trying to say, for
a = 3
a.sign = '-'
Since Lua character strings are immutable objects, you cannot say this
a = "Hello, world"
a = ":"
as you could in a language with mutable character strings.
If you define the interface for vectors correctly, then you can choose to
implement them as tables (possibly protected for debugging) in Lua, or you
can implement them in C. A good interface will let you switch at any
The issue of mutability/immutability is not simply an academic one. It
affects the notion of object equality (there is an (in)famous paper by
Henry Baker on the subject, well worth reading: "Equal Rights for
Functional Objects" -- you can find it here
<http://home.pipeline.com/~hbaker1/> in html and compressed postscript
formats). Object equality is a particularly important concept when objects
can be used as hash table keys. If, for example, strings were mutable, and
you used a mutable string as a hash table key and then mutated (changed)
it, "all hell would break loose." But on the other hand, you really want
to be able to use strings as hash table keys, so Lua wisely implements
them as immutable objects.
An issue for an implementor of atomic immutable vectors would then be
whether or not to make it possible for them to be hash table keys. (This
is an issue for bignums as well.) A naive implementation of an immutable
object makes hashing difficult -- if you use, for example, the storage
address as the hash, you will likely not be able to retrieve keys from the
hash table. The solution Lua uses for strings is to intern the string
(i.e. ensure that there is only one copy of every string in the system);
that would be a possibility for tuples as well (or vectors or bignums) but
it might prove to be inefficient in practice. Another possibility would be
lazy interning, where the object was only interned when used in equality
comparison (including hash table lookup). Yet another option is to insist
that immutable object types come with a hash function which guarantees
that "equal" objects will have the same hash. Many languages provide the
last option, but in practice it is quite difficult to come up with correct
hash functions and incorrect hash functions are generators of very obscure
bugs. My personal preference, if I were thinking about a language from
square one, would probably be lazy interning, although its implementation
is non-trivial as well.