Announcing E 0.8.4: The Birthday Release

[Tyler Close]

> 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