[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
CoordinateSpace
- To: <tribble>
- Subject: CoordinateSpace
- From: Mark S. Miller <mark>
- Date: Tue, 24 Oct 89 22:11:00 PDT
- Cc: <heh>, <eric>, <markm>, <xtech>
- In-reply-to: <Eric>,41 PDT <8910230433.AA28387@xanadu>
Date: Sun, 22 Oct 89 21:33:41 PDT
From: tribble (Eric Dean Tribble)
Complexity Alert!!!!
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.
*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.
Besides that, I see no alternative that is less complex.
I think mashing sets in confuses things even more.
No argument here.
dean