CoordinateSpace

[Eric Dean Tribble <tribble>]

I don't want to cruft table manipulations up with coordinate spaces.
      Normal use of IntegerTables should require no understanding of
      Position types and CSTs.  Otherwise the abstraction has outgrown its
      purpose.

   Let's define a "Vector" as an integer indexed ImmuTable whose domain
   is a contiguous set of integers, and whose least domain element is
   always 0.  WordVector would then be a kind of Vector.  I propose that
   Vectors are the kind of very light weight Tables that you are looking
   for.  Instead of the current n-ary overloaded "list" function, we
   would have an (identically functioning) overloaded "vector" function.
   Obviously, we can overload the definition of "fetch" & "get" of Vector
   to take IntegerVar arguments.

I'm tempted to use the Smalltalk names Array, WordArray, ByteArray,
RunArray, etc rather than Vector.  That way we won't confuse the CAD
developers :-)  Comments?

   *Normal* use of Vectors would not *require* anyone to be cognizant of
   Positions or CoordinateSpaces.  These only come up when we want to
   deal with Vectors as a kind of Table, or when we want to deal with
   Tables in more of their generality, specifically their generality of
   being indexable by things other than integers.  In this latter case,
   being cognizant of Positions & CoordinateSpaces seem to me to be quite
   appropriate.

This brings to mind the cost of ObjectAsPosition keys:  It's hard to
explain.  Oh well.

Do CoordinateSpace objects exist and know what kind of Positions are
appropriate for them?  

The Vector idea makes sense for Array type things.  Can you think of
an equivalent simplification for hash Tables?  They are much harder to
explain.  I can live with just the above simplification, though.

Go for it, Who.

dean