Edited for relevance.

From:    Pavel Curtis
To:      MOO-Cows
Subject: The 1.8.x planned feature list
Date:    Wed, 16 Mar 1994 21:14:38 -0800

OK, at long last, here's my list of everything I am consciously planning to do
in 1.8.x.  Note that `disk-basing' and `multiple inheritance' are not on this
list; the former is, as I've said, in the queue for 1.9.0, and the latter is
not in the plan at all.

There are no release times in this message; I have no estimates available, so
don't bother asking.  Sorry.

[...]

++ New MOO value type: tables
	Tables are like lists except that that map from values to values,
	rather than just from a small range of numbers to values; this is
	useful in a wide range of applications where programmers are trying to
	associate values with arbitrary `keys'.  Implemented using hashing and
	some tricky collaboration with the reference counter, many common
	styles of use will be efficiently performed using side-effects without
	ever showing the MOO programmer anything that violates the current
	model that all values are immutable.

[...]

From:    Pavel Curtis
To:      Robert Leslie
Subject: Re: Simulating LambdaMOO 
Date:    Thu, 21 Jul 1994 15:08:59 PDT

[...]

> Second: Tables. I have not been able to come up with a satisfactory syntax
> for creating these associative arrays within the MOO language. I plan to
> implement tables as a new datatype, but so far I have limited myself to the
> following interface:
> 
>   ...

One thing you didn't mention was iteration over tables.  I envisioned a
construct like this:

	FOR k-var ~ v-var IN (table-expr) stmts ENDFOR

The tilde comes from this:

> Have you considered any input syntax for creating tables in MOO?

I was planning on using

	{key1 ~ value1, ...}

The amusing thing is to consider meanings for the MOO `@' syntax:

	{@table, key ~ value}
	{key ~ value, @table}
	{@table1, @table2}

I like the conceit that the resulting table behaves as if you were searching
the constituent tables and pairs in left-to-right order, so the first example
uses the binding of `key' only if it isn't already bound in `table', the second
example overrides the binding of `key' in table (if any), and the third example
uses only those bindings from `table2' that are for keys not bound in `table1'.

> I think modifying tables should be something as easy as:
> 
>   ;me.tab["newkey"] = "newvalue"
>   => "newvalue"
> 
> But keeping with the rest of the MOO programming philosophy, I think I agree
> that immutability should be preserved.

I completely agree.

> How do you feel about removing keys from a table, or looking up a nonexistent
> key? Is it enough to use the zero value to facilitate these?

That would be inconsistent with the rest of MOO.  We are getting an
exception-handling facility in 1.8.0 (already mostly working...), so I see no
reason to do this kind of result-overloading.

>   ;me.tab = tabledelete(me.tab, "key")
>   => {table}
>   ;me.tab["nonexistent"]
>   => (Error: E_RANGE)

I intended this.  It would be nice to do something prettier than that
`tabledelete' function, but I don't have any good ideas along these lines.  I
think it will be fine to just go with this.

In addition to the `tablekeys' and `tablevalues' functions (which maybe you
don't really need often enough to justify putting them into the server), I'd
definitely suggest a tabular equivalent to the `in' construct for lists;
perhaps `table_binds(table, key)'.  Of course, this is a test on the table keys
while `in' is a test on the list elements, but I think that disparity is pretty
natural considering the disparate uses of the two.

[...]

	Pavel