RE: Announcing E 0.8.4: The Birthday Release Tyler Close (tyler@waterken.com)
Thu, 27 May 1999 20:09:06 -0400

> Is there some semantic trouble we would get into by adding an
> 'implementsSameMapping' method (feel free to substitute a better name)
> to the table protocol?

It would be hell on wheels to implement. If you want to do comparisons like that you should be using a binary tree and not a hashtable.

So maybe E tables aren't tables but binary trees. This means the whole non-determinism thing goes away since there's only one possible ordering. It also means that: 

	? ["foo" => 3, "bar" => 4]
	# value: ["bar" => 4, "foo" => 3]

	? ["foo" => 3, "bar" => 4] == ["bar" => 4, "foo" => 3]
	# value: true

There is precedent for doing this. The C++ STL defines the set<> and map<> templates to be binary trees. They did this because of the more absolute runtime guarantees that can be placed on a red-black tree (slower, but certain).

Union, intersection, difference, etc. operations are all better implemented with tree based sets.

The problem here is that E overloads [] to mean both a list and a table. You're not allowed to re-order a list from what was entered by the user.

If:

("markm", 42)
was a list/array/tuple and maybe also a hashtable, then using [] for a tree would be ok. I also think it would be neat if:

birthday("markm", 42)
was a typed tuple and:

e_lang birthday("markm", 42)
meant "send e_lang the following birthday tuple".

But now I've probably gone too far afield.

Tyler