[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
UnaryFns & Tables
- To: <mark>
- Subject: UnaryFns & Tables
- From: Eric Dean Tribble <tribble>
- Date: Sun, 29 Oct 89 23:54:48 PST
- Cc: <heh>, <xanatech>
- In-reply-to: <MarkS.Miller'smessageofSun>,48 PST <8910300109.AA03054@xanadu>
Good point about the snapshot. Is there a corresponding operation for
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
Actually, It's easier to implement overriding combine than the current
semantics. Right now I assume unique spaces, and error if they
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.
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
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
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
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.