MOX

[RE01 Rice Brian T. EM2]

Once more into the fray...

> > 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?

Logos is traditionally translated as 'the literal word' or 'word denotation'
referring to the objective meaning or definition of words, sometimes more
specifically as nouns. But this only came after Aristotle and
contemporaries. Before this it apparently meant something more like 'the
connected consensus of words' or '... of knowledge', and the former
description arose after it and replaced it.

Aletheia means the unconcealment (appearing) of things in general into the
world (or at least that's how Heidegger puts it ;). This relates a lot to
the ideas I wanted for my ontology system within Arrow. Perhaps the word is
most appropriate for the ontology system (and just sounds pretty rather than
academic, after all no one cares if the Eidos game company is named after
the greek word for 'mask' or 'idea' or 'icon' =). Conventional translations
for the word usually just reduce it to 'truth' or 'beauty'.

As always, I recommend a Google search for strange words that happen to be
talked about in important literature.

> >> 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.

Okay, this kind of explanation (and others below) helps give me an idea of
what MOX means in the TUNES conception of things. I'll try to explain what I
understand it to be below.

> >> 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.

I just re-read this and now have questions about it, just to clarify: you
mentioned above that the tumbler is invisible, but is still required for MOX
object existence. Basically you consider it your underlying unique
identifier (ugh, I hate conversations about those) but you consider the
names or hints to not be part of the meaning of the object. On the other
hand, I may just be confusing your slot concept with your annotation
concept, which I treat fairly similarly in my Slate concepts. But then again
you seem just as unsure as I am. Can you clarify what you want for MOX?

> > 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 :(.

Common Lisp... it has the most useful features, full macros, CLOS (good
enough for me), and optional and keyword arguments.

> >> 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.

Now I am really confused :). What exactly is the status of your identifiers
in MOX? May I use arbitrary-type objects or no?

Before you answer, I also offer you a third option: do you mean to create
two separate MOX languages/interfaces, one for average users and a seperate,
more powerful one for developers? If this is so, how strongly would you be
dividing the two? As a contrast, I consider the weakest division between
base-level and meta-level access for a common language is that for Lisp
and/or Smalltalk: you simply have access to 'eval' + hooks and the
environment (in Smalltalk's case, you hack the bytecode-compiler or
meta-classes). I suppose as long as I've asked all these questions, I'll
tack on one more: do the tumblers fit in at the 'developer' (~meta) level?

> > 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.

Well I didn't mean it would be a MOX operator (which you clarified), but it
still is an operator in the generic sense. (This is pedantic, though.)

> 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!!

Sure, and one of the primary differences between Lisp and Slate, Fare and I
found, was that Lisp auto-evaluates its forms and Slate denotes objects to
obtain (which sometimes require evaluating a thunk but not usually, and
basically needs to be forced).

However, the multi-arrow is a little confusing. If I were to relate it to
some lambda-calculus style ideas, I'd say that referencing active
multi-arrows would return the evaluation of the first branch object *and* a
"continuation" multi-arrow.
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?continuation+passing+style
explains basically what I mean by a continuation. You could also just have
the 'rest' part be a similar thunk instead of a continuation, which is less
confusing.

Either way, though, I still don't understand what a multi-arrow as you
describe it is supposed to mean. How does it fit into the MOX style of
thinking? Come to think of it, what IS the MOX style of thinking? :)

> > 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.

Again, just a mis-understanding. I was describing the relationship between
types as I would in a specification. But I should add that every 'notational
convenience' in some language eventually has some kind of real semantics in
some real context, even if you don't consider the context relevant. So I
assume this means you don't care about this with respect to MOX. (i.e. it
would be part of the larger TUNES system but not visible in MOX)

> >>  - 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.

'Application object'? This word connotes for me CORBA and COM and all sorts
of business logic, which I suppose is unfair :). So do you mean an object
representing the application of a function? This could be useful but
applicative programming is not a magic bullet per se.

[Snipped stuff about persistency.]

> > 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.

Okay, the basic idea in the diagram is simple, and I didn't mis-interpret
that. But multiple values? I take it you mean that successive 'evaluations'
of the multi-arrow return the values successively? If that is so, then it
would be equivalent to a stream ADT.

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

Unfortunately, the multiple values idea only seems to come across as the
same thing that most programmers call streams. Am I wrong?

Well, overall it seems you're mostly interested in re-interpreting and
clarifying what Ted Nelson's Xanadu was trying to do. Just keep working on
the concepts and try to relate them to whatever existing abstractions you
can. If you can manage to clarify and solidify what Fare's written about
meta-text systems, you are welcome to revise the documents there. :) (I grok
them well enough myself, but I am not so concerned about that aspect of
TUNES personally.)

Keep at it...
~