UnaryFns & Tables

[Eric Dean Tribble <tribble>]

Good point about the snapshot.  Is there a corresponding operation for
      Orlgs?  

   No.  The one that immediately came to mind is: 
   "a->combine (b->notKnownSharedWith (a))" but that confuses domains
   with ranges.  Now that it is resolved that Orgls are never
   multi-valued mappings, I think we should define such an operation.
   Perhaps it should replace "combine".  You can see why it was avoided
   back in the multi-valued mapping days of Orgls.  As the Ent
   implementor, what do you think of replacing "combine" with this new
   operation? 

Actually, It's easier to implement overriding combine than the current
semantics.  Right now I assume unique spaces, and error if they
overlap.

      Is there a compelling need for dynamically tracking subTables?

   The non-snapshot semantics was inspired by the programming language
   notion of lexical naming environments as nesting contours.  ...

That's a 'no', right?  :-)  I think composite tables are the inverse
of the structure in nesting contours, but it's completely unimportant.
Never mind.

   Given "asImmutable()" it is easy to express a snapshoting construct
   using the non-snapshotting one.  But not vice versa.  We have here a
   more orthogonal separation of concerns: composition vs snapshotting.
   The non-snapshotting one is also perfectly easy to code (as
   demostrated by the fact that it is already coded very simply).

The complexity arises because your building a simple abstraction on
top of a complicated one.  Sharing updateable state lets us in for
all sorts of non-local side-effects - the very bane of data-structural
engineering :-)  If we find we need it later, we can build it, but
it's quite difficult to explain, and I can't imagine a clean way to
use it.

It's interesting to note that I'm not as allergic to SubTables (that
represent a side-effectable, shared pice of a table), even though they
are semantically equivalent.  I think it's because I haven't thought
about them deeply.

   These are just counter-arguments that come to mind.  I actually have
   no significant preference.  If no one else does, then we have one vote
   for snapshotting.

I'm ballot-box stuffing.  Two to one in favor of snap-shotting.  :-)
Besides, I need them.  

   Despite allegations, this is actually our only "academic" argument, as
   no one has any use yet for composite tables.  Once there's a use, I
   suspect it'll be easier to resolve.

I think I'll be using snapshot combining for canopyCrums in the Ent.
We'll see.  In the meantime, noone should waste implementation effort
on either solution.

   The above proposed new Orgl operation doesn't resolve the issue, as
   Orgls are side effect free so the question of snapshotting is
   irrelevent.

Snapshotting is relevant.  We need the snapshotting operation for
Orgls.  We don't yet need the state-sharing one.

Conclusion: let's not implement either one yet (unless it's necessary
to complete the Orgl semantics).  When someone needs one, announce it.

dean