Tables

[Hugh Hoover <heh>]

I've got a new table hierarchy laid out (in Smalltalk) and I thought I'd
present it for criticism (or awe :->) before finalizing it.
  There are 2 main abstract classes:
CLASS(ROTable,Heaper)
CLASS(Table,ROTable)

and 2 sort-of abstract:
CLASS(SEFTable,ROTable)
CLASS(TableView,ROTable)

ROTable is Read-Only Table.  It provides basic read access protocol.
Table is your basic TableBang - it adds write protocol.
SEFTable is Side Effect Free Table.  It is ReadOnly with the additional
				     constraint of not being side-effectable.
TableView is essentially a UnaryFn that responds (only) to ROTable protocol.
	I expect to use these quite heavily to provide efficient access
	to large blocks of data where a primary operation is to get a
	subsection of the larger table.

There are also several implementation classes defined:
CLASS(IntegerTable,Table)	-- dean's integer indexed table.
CLASS(MapTable,Table)		-- MarkM's mtable.
CLASS(CompositeTable,Table)	-- a reimplementation of MarkM's
				used to combine smaller, disjoint tables.
CLASS(WordVector,SEFTable)	-- Eric Hill's efficient, useful table.
				(which will require some protocol changing)
				Eric, will this cause you significant probs?

In addition to having the standard access routines, tables will also respond
to a run protocol, where a run is defined as:
a Charming sequence of equal objects.

Charming is our (weak) definition of contiguous - ask MarkM or Dean for
details, but for all our early purposes, it works just fine.

Well, with this specification of tables, I think we've hit the important points
we need for implementations (esp fe requirements) and it should be fairly
easy to get efficient implementations out of this too.

Comment?

--Hugh