MOX

[Brian P Templeton]

"RE01 Rice Brian T. EM2" <BRice@vinson.navy.mil> writes:

> 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.
> 
Sorry, but I don't (yet) know Greek, though I've been planning to try
to learn it (but don't have enough time ATM): what do `logos' and
`aletheia' mean?

>> 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.
> 
Tumblers are not really visible to programmers in MOX, normally - they
are just a detail of how objects are uniquely idenfied. No programmer
(except a MOX developer) will care what an object's tumbler is, as
long as they can produce a valid arrow to the object.

>> [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.
> 
Worlds and spheres are getting more influential by the moment! I just
had an excellent idea concerning source code and 'verses, I think, but
I'm not sure how to write it yet.

>> 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).
> 
What Lisp will it be in: CL, Scheme, or some other Lisp? I'd like to
test it, but most non-trivial Scheme programs are not portable between
implementations :(.

>> 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.
> 
Well, no, the names or the colors have no relation to how the object
is identified; sorry for that ambiguity. Basically, labels and colors
are conveniences for developers.

> 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.
> 
I'm not familiar with `boxing'. `|...|' is *not* an operator; it is
just to make the example easier to understand.

However, as for quoting, this seems like a good time to introduce
activation/dectivation. Here are some examples:

 - An active application object (see below) would, when reference,
   return its evaluation; an inactive application object could be used
   as a thunk. (Well, I'm certainly not sure about this one.)

 - An active arrow, when referenced, returns the evaluation of the
   object that it points to; an inactive arrow is self-evaluating.

 - An active multi-arrow, when referenced, returns the evaluation of
   the object that the first branch points to; an inactive multi-arrow
   is self-evaluating.

After writing these examples, I am surprised to find that active
versus inactive seems to simply mean self-evaluating versus
non-self-evaluating!!

> 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).
> 
No, the `|...|' operator is simply a notational convenience.

>>  - 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.
> 
I no longer think that sequences are necessary, and I didn't at the
time of this posting; I have now, however, decided that something like
an application object would be best. I now have an idea about source
code that may make metaprogramming and persistance easier.

> 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?
> 
A multi-arrow is conceptually something like this:

                              x   y   z
                              ^   ^   ^
                               \  |  /
                                0 1 2
                                \ | /
                                 ---
                                  |

where 0, 1, and 2 are `branch numbers' and x, y, and z are objects in
some 'verse. When the multi-arrow is active, it is considered to point
to only the object at the end of the first branch - in this case, x -
and when inactive, well, it is a complete multi-arrow, not pointing to
anything, but just there. They will probably be used to implement
multiple values.

You are off; multi-arrows are *not* collection primitives. They are
intended to be used as multiple values of sorts.

>> 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.
> 
Yes, I think so. I'm usually IRCing somewhere between 8:00 to 10:00 PM
EST.

>> 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.
> 
I hope you are well again soon.

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

Best regards,
-- 
BPT <bpt@tunes.org>	    		/"\ ASCII Ribbon Campaign
backronym for Linux:			\ / No HTML or RTF in mail
	Linux Is Not Unix			 X  No MS-Word in mail
Meme plague ;)   --------->		/ \ Respect Open Standards