CoordinateSpace

[Mark S. Miller <mark>]

Date: Sun, 22 Oct 89 11:44:11 PDT
   From: heh (Hugh Hoover)

     Since tables have a coordinate space, shouldn't coordinate spaces be moved
   from febe to xpp?

Unfortunately, yes.  Oh well.  I suppose this means that MetaVariable
will end up moving to xpp too.  

     Also, I'm building the initial tables with only 2 kinds of cs, integer
   and heaperAsPosition.

I would think that the descendant of MTable (MapTable?) could be
parameterized with a coordinate space, as it's internal implementation
is just a generic hash table.  In any case, the above two should be
good enough to start with.

     implication of coordinate space in tables:  a composite table can have only
   one coordinate space - which is enforced during construction.  Seems
   reasonable, I don't know what I'd do with a mixed one...

Correct.  It should cause a BLAST to try to compose two incompatable
tables, where incompatable means that they have incompatable
coordinate spaces.

     A thought..  If you had a table with a set-ordered cs, wouldn't that
   replace sets (or setbangs, depending on table)?  Main difference is
   a streamlined protocol for sets.  Of course, the sematics are a bit different
   for iterator(), count()... since they work on the contents of a position
   rather than the positions.  So, having sets as a subclass of seftable isn't
   quite useful.

Interesting.  I now think it makes more sense for Sets and SetBangs to
be their own types, so they can have a Set oriented protocol, but have
a SetBang implementation that wraps a MuTable, a SetView
implementation that wraps a ScruTable, and a Set that wraps an
ImmuTable.  The type hierarchy for these kinds of sets should probably
parallel the hierarchy you've come up with for tables (which I really
like).  How about MuSet, ImmuSet, and ScruSet?  (Yes, I'm serious)