MOX

RE01 Rice Brian T. EM2 BRice@vinson.navy.mil
Sat Jan 19 21:56:01 2002


Hi, it's nice to have time to talk again.

Brian P Templeton <bpt@tunes.org> writes:

> I have begun preliminary work on a system called MOX. (``MOX'' stands
> for ``MOX Obviates Xanadu'', since it was originally going to be a
> hypertext system; `mox' is also a Latin word for `soon', with
> allusions to the common phrase `RSN'.)

Interesting reference. Actually in recent times I've considered renaming
Arrow to one of a few terms in ancient Greek, to honor some of the
philosophical ideas I think it relates to. 'logos' and 'aletheia' are at the
top of the list, and there are a few others.

> It is centered around a datastructure called an arrow, in honour of
> Brian Rice's Arrow system - I don't yet understand Arrow, but after
> attempting to read the Arrow papers one more time, I thought of
> locatives and how an ``arrow'' might be something like a locative
> (though I knew that that is not what an Arrow arrow is).

> An arrow acts as a pointer into a 'verse (short for ???verse). A
> 'verse, the allusion being to poetry and rhyme, acts as an environment
> in other languages, except that instead of being a mapping between
> symbols and objects, it is simply a collection of objects, internally
> identified by a tumbler (a word borrowed from Xanadu) - though I may
> change `tumbler' to something else, since I don't really know what
> would be like in Xanadu other than being of the form 0.x.y.z (I could
s/what would be like/what they would be like/
> probably do some research on it, though).

That sounds like what I was intending (though I didn't properly document)
with the Slate language system. Eventually the idea was to use arbitrary
quoted objects as identifiers (annotations for path elements) to
obtain/denote the available objects in the system. Still, I can't think of a
good term for it either, except perhaps 'name'. Remember that if you
consider '.' in an algebraic sense, it's an associative, non-commutative
operator, probably using an (quoted?) empty string as its identity element
(i.e. "''.foo" = "foo"); so you can describe it programmatically. It happens
to have the same semantics as character- or string-catenation into strings,
although at a separated level of abstraction.

> [Those who've listened to me promise to post to the TUNES list on IRC,
> besides having learned how good I am at procrastination :), may notice
> that I've generalized from a huge Xanadu-like ``Objectuverse'' to
> smaller 'verses. I think that this was a good design decision, but I
> may reverse it if necessary. The worlds thread from a few years ago,
> Alan Grime's Sphere project, and other ideas were influential here.]

I'll have to look back at that.

> An `object' in MOX is simply something that has a tumbler, some slots
> (well, zero or more slots, probably), and hints. (The name `hints'
> will probably change to `annotations' later on, as it appears that
> Fare came up with this idea a long time before I did.) I am not quite
> sure how the slots will work yet.

This is what makes me think of the Slate system the most. Within that system
I was using different aspects of the proposed MetaObject protocol as the
place for hints, so that they were meta-objects in the generic sense that
the CLOS MOP considers things. Objects were sets of slots in the most
generic logical sense. I have to say that I haven't overcome all of the
problems that arose when trying to meld this idea into the TUNES ideal.

> [After considering recent ideas I've had concerning
> protocols/interfaces, specification languages, etc, I may change the
> semantics of objects completely, but then again, I may not. MOX
> doesn't yet exist and so /ipso facto/ doesn't even have ten users, so
> unlike the designer of `make' I don't even have a *bad* excuse :).]

Well, I may have some time now to implement the ideas I completed for Slate
once I get back. It'll probably be in Lisp first instead of in Arrow as I
intended, mostly due to my difficulties in trying to make an architecture
within Arrow that would allow for those things (I think these problems are
not insurmountable; I just need to talk these ideas out a little to refine
my decisions).

> In MOX, source code is merely a sequence of arrows, possibly, e.g.
> using the Lisp tradition of using lists to represent function
> applications. However, there are *no symbols*. It will likely be
> possible to attach a default label to an object, through hints, but
> there is no particular reason why one must use labeled objects at all.
> In fact, using hints, someone could implement, say, a system where
> objects were identified by color (yes, that's probably a really stupid
> idea, but there are most likely some interesting variations on it).

Interesting. It sounds similar to what I mentioned above, and there's
certainly space in the Slate type-system to allow for the various color
types, obviously the larger system needs mappings from these color objects
to objectively-defined (e.g. scientific) measurements in order to be useful.

Taken from your self-reply:

> > Some interesting things appear to be possible with arrows; for
> > example, if MOX were to adopt the Lispish convention of making source
> > code simply a series of sexps, then MOX could implement Arc's
> > ``name-munging'' (I have no idea what the real name of the ``feature''
> > is) cleanly. (In Arc,
> >     (eqcar x y) === (eq (car x) y)
> > but in MOX, something like
> >     (|eq||car| |x| |y|) === (|eq| (|car| |x|) (|car| |y|))
> > with `|...|' denoting an arrow to the object whose canonical name is
> > `...', could be cleanly implemented, I think.)
> > 
> Oops. I forgot to mention that this would probably rely on a sort of
> arrow called a multi-arrow, which could also be used for multiple
> values.

I interpret this `|...|' operator as the reification of the reference (as an
arrow), which seems like boxing (Fare has used this term several times; this
refers to the Eval/Quote and modal S4 logic papers by Giraud). Boxing is
similar to quote except for quote's relation to eval; it's similar also to
ML's referencing operator, which is what allows for state in ML.

As for the 'real name' of the name-munging idea, it sounds like an extension
of the DWIM features that InterLisp had in the 70's for letting the listener
guess what a user means when an environment lookup fails. I'm just referring
to the fact that it was non-deterministic semantically. With your ||
operator, you're introducing the meta-level type of string that is an
extension (level 2) of the distinction I made earlier between '.' (level 1)
and string-concatenation (level 0 abstracted from strings).

>  - Synopsis -
> MOX is based on a datastructure called an arrow (in honor of Brian
> Rice's excellent Arrow system, which it seems that no one other than
> he understands :)). Source is just a sequence of arrows ``pointing''
> to an object in a 'verse, which can orthogonally or non-orthogonally
> make objects persistant, and [FIXME: is this a good idea? - probably
> not] the same arrow will always point to the same object, unless,
> perhaps, a hint is provided to the contrary. A 'verse is a collection
> of objects. There are no symbols in MOX, though they can be emulated.
> MOX combines development and hypertext in a somewhat novel way.

As for the notion of source you use, it'd be useful to give an explanation
of the reason for using sequences as your code shape; perhaps by explaining
what the sequencing is supposed to mean semantically, you (we) could arrive
at a better understanding.

As for persistency, I am reminded of the Linear Naming paper by Alan Bawden,
where a name being linear corresponds to trading your reference to it with a
reference to something else, which breaks an implicit 'return link' back to
you; it resolves to manual GC in a simplified form. Other systems use this
in a linear typing sense; you annotate an object as being allocated
linearly, and it is deleted from the system heap right when you lose the
reference to it. This works usually by just holding it on the stack and
requiring multiple references to only use heap-allocated objects (here we
pretend that the linearly-allocated objects are in the heap semantically).

About multi-arrows, I'm not sure what kind of reference this would be,
perhaps you just need a collection primitive, and this is your intent. Am I
off?

> This post is poorly organized and incomplete, but it will hopefully
> give you some idea of the basic concepts of MOX. All questions are
> gladly answered and I would very much appreciate any feedback at all.

Not too bad an explanation. Of course I'd like to hear more at some point.
Perhaps an IRC (i.e. real-time) meeting would be best.

> BTW, water, if you read this, am I correct in predicting that you'll
> arrive in San Diego, CA soon? (You probably can't answer that :).)

I'm on the ship at the pier right now, but I'm in the middle of dealing with
a pretty bad flu. So I'll not be in town this time. I only had 16 hours of
time off anyway.

It's pretty likely, though, that I'll be around again while doing software
work.

Thanks,
~