A bunch of stuff about Slate and Pidgin...

[RE01 Rice Brian T. EM2]

Hey Lee and all Tunesers,

I'm back on land (although today is duty time; please make sure to reply to
my Bespin address) and I'll have 2 out of every 3 days off for the next
couple of weeks. I read over the recent discussions in #tunes on IRC, and
I've been reading up on various books of mine while at sea. I have a lot of
ideas, and luckily most of them won't interfere at all with the Pidgin
framework. In particular, I'm re-working the ideas about ":" and "^" and
such (they are sooo troublesome; perhaps you have some ideas on the
subject?). Also, I've been looking at Tunes HLL documentation (in meat
space) and trying to address the requirements point-by-point using what we
already understand about Slate.

Here are some examples of what I'm talking about:

Concurrency
	We know what policy we want concerning this (demand-driven immutable
structure update), but what about explicit constructs for concurrency? In
other words, where in the MOP would this be handled? Ideally, we need a
single point where the user can give the compiler hints as to where
concurrency can be introduced safely. Probably more accurately, a single
point is needed where consistency is needed (like how a consensus would be
required for the various objects comprising a thread). This requires other
things to be specified first, but we need to keep it in mind.

Meta-Structure
	This is fairly simple. Your notes about "maps of maps" in the Pidgin
source could be expanded to a graph notation by using the map as an
adjacency list for each object considered. Also, it would probably be
beneficial to reify not just single objects, but collections as well. This
would make state-update and such (in those ways we discussed: using MOs to
change the parent or the parent's parent or the MO or the MO's MO or the
enclosing namespace or etc. or combinations of these considered
orthogonally) much simpler to express using this meta-level representation
as a language for expressing where the critical references to track are.
	This (the means for creating the meta-level representations) could
be used as a basis for expressing both the lookup and apply strategies, so
it would definitely be a good MO component IMO. Remember that we're
considering our MO's in the sense that Guaranį takes multiple MO's and
composes them, so this is one more step towards a complete and hopefully
orthogonal architecture.
	One thorny issue is that this representation will be at an abstract
level, so the usual ways of referencing objects won't work. It doesn't seem
like the Right Thing to just draw up some arbitrary low-level address space,
because migration and such would be bothersome to track. Potentially, these
graphs (given a Tunes environment) could be widely distributed, so even a
global identifier would be insufficient, especially where the graph extends
across context levels.

Linearity of References
	There are a few things to cover here. For instance, this is the
basis for persistence and the determination of garbage-collection
requirements, so it's a significant issue. (There is also the side note of
weak or pseudo-references and where these would fit in. My experience on
that is not sufficient yet for expert discussion. Can anyone provide some
input on it?). Specifically, we need a place in the MOP to annotate this.
	Some initial specs that I could give you for this is that most
nonlinearity could be absorbed by "parent" references, with linearity
optionally provided there by the means suggested in Bawden's thesis. Another
note is that "<" is *always* linear (as far as I've discussed with various
people). "meta" looks very likely to be useful if limited to linearity,
since the one-to-one relationship between MO and object would keep the MO
design simple (all structures relate or center around that one object
(implicitly), which obviates the need for those references across context
level that I mentioned above as so troublesome to me for now.)

I'll give some more examples, but these should be enough for now to chew on.
Right now, making sure that I understand how to build the implementations of
":" and "^" within the language seems to be the central goal. Tying into
that is this scheme for equational specification that I'm putting together.
It's like those used in functional programming systems, but I'm borrowing a
bit of concepts from model theory and such, and the Tunes choice axiom stuff
is definitely a big part.

Hmm... choice axiom... that reminds me that there are a LOT of points that
I'd like Fare specifically to clarify or give paper references for and to
correspondingly update those specific points in the Tunes HLL Requirements
and Semantics pages. I'll get to those tomorrow.

~