Re: The real problem with vectors and Lua

[RLake@...]

Dylan Cuthbert escribió (hace tiempo):

> I don't mind position:set_x( 10 ), but this is getting away from my 
point,
> my problem is the fact that these vectors are classed as *tables* in 
Lua.  I
> need them classed as atomic objects like strings.  There is another mail 
in
> 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 
a
> 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 
example:

  a = 3
  a.sign = '-'

Since Lua character strings are immutable objects, you cannot say this 
either:

  a = "Hello, world"
  a[6] = ":"

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 
moment.

<side-issue type="theoretical">

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.

</side-issue>

Rici