Region questions

[Mark S. Miller <mark>]

Date: Fri, 10 Nov 89 11:53:45 PST
   From: heh (Hugh Hoover)

     I've started on regions, assuming that they will be subclasses of Heaper,
   and will have approximately the protocol you wrote out in your note yesterday.
     I have a couple of questions on how everybody thinks these beasties should
   act.   But First! a message from our ...  no well, a note on hierarchy.
   I've set things up so that Region and DiscreteRegion are both abstract
   superclasses.  

Recapping our verbal discussion, it seems like a good idea to no
longer use Discrete vs non-Discrete as a class distinction.  Instead,
all Regions should implement the protocol of a Discrete Region (the
"stepper" message), as well as an "isDiscrete()" message.  I actually
prefer that the message be called "isEnumerable()" or "isCountable()".
It is true iff the set of positions represented by the Region is
countable (as distinct from finite).  Exactly in the case that this
message returns true, stepper() will succeed in returning a Stepper,
otherwise it'll BLAST.  Alternatively, we could replace both with the
message "fetchStepper()" which returns NULL if the set of positions in
the region is uncountable, and returns a Stepper otherwise.

The reason I'd like to remove this class distinction is that I like
the orthogonal class distinction "Interval" for a contiguous region on
a fully ordered space that answers to "lowerBound()" and
"upperBound()".  If we had both distinctions, then we'd also need a
DiscreteInterval class that was a subclass of both.

Uncountable regions are far from academic.  They occur as soon as we
try to support graphics and CAD: "rot (basicSpace (cat_Float), 3)".
Nevermind that floats are countable.  We are using floats to
imperfectly represent reals.  As Ravi points out, floats have no
consistent theory of their own, and they certainly aren't rationals. 

Here's a wild idea:  We can avoid extending IntegerVar to being able
to represent infinity by having a message "isFinite()" that has the
same relationship to "count()" that "isCountable()" has to
"stepper()".  

   The two implementation regions I'm creating are
   LinearRegion (should that be LinearDiscreteRegion?) and SetRegion.  I'll do
   CompositeRegion later.  LinearRegion is simple, and specified with a lower
   and upper bound (IntegerVars, so far).  It provides an extra bit of protocol
   for the bounds (lowerBound, upperBound).

LinearRegion --> Interval
delete LinearDiscreteRegion;
lowerBound() and upperBound() should both be declared as returning a
"Position *".  For integer spaces they should actually return 
"Integer *" instead of IntegerVar.  For optimization purposes, we need
hand-mangled versions for these message names for class
IntegerInterval that do return IntegerVars.

     Now, the questions:
   1) If the region is empty, which messages should blast?  I currently don't
   blast on any, the only distinction is that isEmpty is true.  Of course,
   lowerBound and upperBound are meaningless, so they probably should blast.

What are all the currently considered messages?  I doubt that any
should blast.  For an empty Interval, I like the idea that lowerBound
is zero (inclusive) and upperBound is zero (exclusive).  The critical
thing is that lowerBound be no greater than upperBound

   2) who (class-wise) is resposible for setting up the regionType?  Where do
   we get the appropriate set of orders and dsps?

   2a) who (programmer-wise) is responsible for setting up the regionType? Where
   do we get the appropriate set of orders and dsps?

Good questions.  No good answers yet.  What do you think?

   --Hugh
   p.s.
     lowerBound (inclusive) to upperBound (exclusive)

Yup.