compose, transform and getSlice

[Mark S. Miller <mark>]

Date: Sun, 22 Oct 89 12:34:31 PDT
   From: heh (Hugh Hoover)

     How difficult is it to remap the UnaryFn ancillary protocols into something
   more like a table oriented protocol.  I've looked at it a bit and it doesn't
   look too bad.  Major changes:
   restrict::of() -- instead of returning the original argument if the test fails,
     it should return nil.
   well, the of() should be fetch(), in which case this is a TableView - which
   means that maybe we DO want to implement the compose/restrict protocol for
   TableView.  

Very good.  I like it.  I think the appropriate translation of "of" is
"get", not "fetch".  This way, "of" users can assume that the normal
return isn't NULL, which is essential for good looking functional
composition notation (the reason we made the fetch/get distinction).

What does "count" mean for Tables?  I assume it is the cardinality of
the domain of the Table.  If we have computed-tables over integer &
real domains, does that mean that the return type of "count" (probably
IntegerVar) must be able to represent aleph-null?  Two-to-the-aleph-
null?  Whose number theory of infinities do we like?  I suppose we had
to figure this out anyway for the representation of enclosures
(although enclosures would seem to need infinite ordinals instead of
infinite cardinals).  Also how dishonest would it be to pretend that
we've got two-to-the-aleph-null *float*s?

This does point out a significant stylistic difference between Tables
& UnaryFns.  Tables are built so that you can inquire about the nature
of their domain.  UnaryFns were thought to be more like functions in
programming languages, in which it is a type checking error to apply
it to something outside its domain, but is inherently in the nature of
a correct program to only apply it correctly.  However, given the
requirement that a shared server properly reject all invalid user
input, and the fact that UnaryFns are passed (by COPY) across the
orgls&berts interface, making UnaryFns more Table-like seems quite
appropriate.  

(Note the additional semantic difference between passing objects by
COPY vs by PROXY: Pass-by-COPY objects cannot lie or cheat.  I.e., the
receiving side of the connection defines the code they use to respond
to messages, and so can make sure that received objects act according
to the contract for their type.  In the above case, this means any
pass-by-COPY UnaryFns that are received by the backend that claim that
integer(3) is in their domain will then act accordingly.  Unless there
is a bug in the backend code.)

Given that we do this, I like the new notion of a restricted UnaryFn
much better than the one I implemented.  Note that the current
definition of a RestrictedSet as a composition of RestrictedUnaryFns
is subsumed (and made much more elegant) by the already defined Table
composition operation.  It is made much more elegant by removing the
hidden "isTaken" property of a RestrictedUnaryFn.  Instead, this is
replaced by the notion of the function being defined only over a
restricted domain.  Given that, the old kind of RestrictedUnaryFn (in
which we have the identity mapping everywhere outside the restricted
region) can be composed from this new kind (in which the function is
visibly undefined outside the retricted region) by: 
oldKindOfUnaryFn = compose (newKindOfUnaryFn, identity())

   But then, what does the current UnaryFn protocol mean without
   Tuples?  That needs to be recast in Iterators.  Or does it?  Can it be done
   purely with a table form?

Purely in Table form.  Instead of TupleTransform, we have
TableTransform.  Instead of GetSlice, we have GetDimension.  etc...  I
see no need for any of this on Iterators.

   please excuse my ramblings.  I've only been running on 1/2 cylinder for a
   couple of days.  I have brief moments of clarity, but I'm mostly mush...

Well, you sure had me fooled.  Good stuff.

P.S.  For all the compositions, it seems better to me to say
a->compose (b) than the current compose (a, b).  I propose we add this
to the protocol, and document the old non-member function as 
#ifdef OBSOLETE (i.e. put it into an "#ifdef OBSOLETE" section.  I'd
say this constitutes clear warning).  I believe Dean suggested this
change.