UnaryFns & Tables

[Mark S. Miller <mark>]

Date: Mon, 23 Oct 89 15:12:11 PDT
   From: tribble (Eric Dean Tribble)

      Date: Mon, 23 Oct 89 14:56:59 PDT
      From: mark (Mark S. Miller)

      Oops.  I noticed an interesting terminological gotcha waiting to
      pounce on us.  "compose" on Tables corresponds to putting a bunch of
      RestrictedUnaryFns together into a RestrictedSet, but is completely
      different than "compose" on UnaryFns themselves. 

   I didn't get this at all!  What does compose on Tables mean?  I
   thought it makes a table with all the pairs in both tables or some
   such (like combine).

Right.  Except that the composite table continues to track changes to
the other two tables, and there is a priority ordering of the tables,
so if they both define a value for a given key, the first one wins.

"compose" on UnaryFns on the other hand is nothing like "combine".
When two tables are combined, their domains must be compatable, and
the new domain is the union of the two old domains.  

In other words, when we table1->occlude (table2), the resulting
function is

Heaper * OccludingTable::fetch (Position * key)
{
    Heaper * result = table1->fetch (key);
    if (result) {
	return result;
    } else {
	return table2->fetch (key);
    }
}

When two UnaryFns, f and g are composed f->compose (g), the range of g
must be compatable with the domain of the "f", and the resulting
function is

Heaper * CompositeUnaryFn::fetch (Position * key)
{
    Heaper * itermediate = g->fetch (key);
    if (! intermediate) {
	return NULL;
    } else {
	return f->fetch (intermediate);
    }
}

Note that the resulting domain is the subset of the domain of g for
which the corresponding range elements are in the domain of f.  This
will make it quite difficult for the composite UnaryFn to accurately
answer questions about its domain.  This may be a serious problem in
trying to unify Tables and UnaryFns.  For example, what does
CompositeUnaryFn::count do?