MOX

[Brian P Templeton]

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

> Once more into the fray...
>=20
>> > Brian P Templeton <bpt@tunes.org> writes:
>> >=20
>> >> I have begun preliminary work on a system called MOX.=20
>> (``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'.)
>> >=20
>> > Interesting reference. Actually in recent times I've=20
>> 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=20
>> 'aletheia' are at the
>> > top of the list, and there are a few others.
>> >=20
>> 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?
>=20
[...good explanation snipped...]
>=20
>> >> 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).
>> >=20
>> >> An arrow acts as a pointer into a 'verse (short for ???verse). A
>> >> 'verse, the allusion being to poetry and rhyme, acts as an=20
>> environment
>> >> in other languages, except that instead of being a mapping between
>> >> symbols and objects, it is simply a collection of objects,=20
>> internally
>> >> identified by a tumbler (a word borrowed from Xanadu) -=20
>> 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=20
>> 0.x.y.z (I could
>> > s/what would be like/what they would be like/
>> >> probably do some research on it, though).
>> >=20
>> > That sounds like what I was intending (though I didn't=20
>> properly document)
>> > with the Slate language system. Eventually the idea was to=20
>> use arbitrary
>> > quoted objects as identifiers (annotations for path elements) to
>> > obtain/denote the available objects in the system. Still, I=20
>> 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,=20
>> non-commutative
>> > operator, probably using an (quoted?) empty string as its=20
>> identity element
>> > (i.e. "''.foo" =3D "foo"); so you can describe it=20
>> programmatically. It happens
>> > to have the same semantics as character- or=20
>> string-catenation into strings,
>> > although at a separated level of abstraction.
>> >=20
>> 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.
>=20
> 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 wha=
t I
> understand it to be below.
>=20
>> >> 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.
>=20
> 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 ag=
ain
> you seem just as unsure as I am. Can you clarify what you want for MOX?
>=20
>> > Well, I may have some time now to implement the ideas I=20
>> completed for Slate
>> > once I get back. It'll probably be in Lisp first instead of=20
>> in Arrow as I
>> > intended, mostly due to my difficulties in trying to make=20
>> an architecture
>> > within Arrow that would allow for those things (I think=20
>> these problems are
>> > not insurmountable; I just need to talk these ideas out a=20
>> little to refine
>> > my decisions).
>> >=20
>> 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 :(.
>=20
> Common Lisp... it has the most useful features, full macros, CLOS (good
> enough for me), and optional and keyword arguments.
>=20
Excellent... for some reason I thought I had heard that you strongly
disliked CL, but I'm probably misremembering.

>> >> 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=20
>> objects at all.
>> >> In fact, using hints, someone could implement, say, a system where
>> >> objects were identified by color (yes, that's probably a=20
>> really stupid
>> >> idea, but there are most likely some interesting variations on it).
>> >=20
>> > Interesting. It sounds similar to what I mentioned above,=20
>> and there's
>> > certainly space in the Slate type-system to allow for the=20
>> various color
>> > types, obviously the larger system needs mappings from=20
>> these color objects
>> > to objectively-defined (e.g. scientific) measurements in=20
>> order to be useful.
>> >=20
>> 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.
>=20
> Now I am really confused :). What exactly is the status of your identifie=
rs
> in MOX? May I use arbitrary-type objects or no?
>=20
``Identifiers'' are meaningless. Objects are referenced simply by
providing an arrow to it; an arrow just contains the tumbler of the
object. So, I guess, the real identifier of an object is the tumbler.
Any hints specifying a name, color, graphic, noise, or any other
convenient identifier exist just for convenience.

Hrm... it seems to me that a tumbler is roughly isomorphic to a symbol
in Lisp, in that it is supposed to represent a single object at all
times but can change... something more permanent seems necessary, too.

I had an interesting idea related to this based on thinking of a
'verse as a set of points, each point representing an object
(reminiscent of the `Timeless Theory' bag in _The End of Time_...).
Instead of simply having points identify object locations, objects are
located by following a vector from the current location (I just began
reading _The End of Time_ today, and already it's seeming to have some
similarities to MOX ideas!...probably not coincidental). Therefore, if
you follow an arrow -- a vector -- from a different location, it could
very well end up pointing to a different object.

> 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 sepera=
te,
> 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?
>=20
No.

>> > Taken from your self-reply:
>> >=20
>> >> > Some interesting things appear to be possible with arrows; for
>> >> > example, if MOX were to adopt the Lispish convention of=20
>> 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=20
>> the ``feature''
>> >> > is) cleanly. (In Arc,
>> >> >     (eqcar x y) =3D=3D=3D (eq (car x) y)
>> >> > but in MOX, something like
>> >> >     (|eq||car| |x| |y|) =3D=3D=3D (|eq| (|car| |x|) (|car| |y|))
>> >> > with `|...|' denoting an arrow to the object whose=20
>> canonical name is
>> >> > `...', could be cleanly implemented, I think.)
>> >> >=20
>> >> Oops. I forgot to mention that this would probably rely on=20
>> a sort of
>> >> arrow called a multi-arrow, which could also be used for multiple
>> >> values.
>> >=20
>> > I interpret this `|...|' operator as the reification of the=20
>> reference (as an
>> > arrow), which seems like boxing (Fare has used this term=20
>> several times; this
>> > refers to the Eval/Quote and modal S4 logic papers by=20
>> Giraud). Boxing is
>> > similar to quote except for quote's relation to eval; it's=20
>> similar also to
>> > ML's referencing operator, which is what allows for state in ML.
>> >=20
>> I'm not familiar with `boxing'. `|...|' is *not* an operator; it is
>> just to make the example easier to understand.
>=20
> 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.)
>=20
>> However, as for quoting, this seems like a good time to introduce
>> activation/dectivation. Here are some examples:
>>=20
>>  - 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.)
>>=20
>>  - An active arrow, when referenced, returns the evaluation of the
>>    object that it points to; an inactive arrow is self-evaluating.
>>=20
>>  - 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.
>>=20
>> After writing these examples, I am surprised to find that active
>> versus inactive seems to simply mean self-evaluating versus
>> non-self-evaluating!!
>=20
> 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).
>=20
> 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 le=
ss
> confusing.
>=20
> 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? :)
>=20
For more information on the MOX style of thinking, please locate
memory 0.340.704.205.7194. If that turns out to be a reference to
another memory, then please locate *that* memory. If *that* turns out
to be a reference to another memory, then please locate /that/ memory.
If /that/ turns out to be a reference to another memory. then ...

>> > As for the 'real name' of the name-munging idea, it sounds=20
>> like an extension
>> > of the DWIM features that InterLisp had in the 70's for=20
>> letting the listener
>> > guess what a user means when an environment lookup fails.=20
>> 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=20
>> that is an
>> > extension (level 2) of the distinction I made earlier=20
>> between '.' (level 1)
>> > and string-concatenation (level 0 abstracted from strings).
>> >=20
>> No, the `|...|' operator is simply a notational convenience.
>=20
> Again, just a mis-understanding. I was describing the relationship between
> types as I would in a specification. But I should add that every 'notatio=
nal
> 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)
>=20
In a good editor for MOX, I imagine that source might be displayed
like this:

    ([myfunction] [arg1] [arg2])

where [...] is colored in some way and `...' is the contents of the
`name' hint of the object. IOW, even names are just notational
conveniences, and do not affect the ``pure'' semantics of the system,
although developers will probably think in terms of names.

>> >>  - 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=20
>> other than
>> >> he understands :)). Source is just a sequence of arrows=20
>> ``pointing''
>> >> to an object in a 'verse, which can orthogonally or=20
>> non-orthogonally
>> >> make objects persistant, and [FIXME: is this a good idea?=20
>> - 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=20
>> collection
>> >> of objects. There are no symbols in MOX, though they can=20
>> be emulated.
>> >> MOX combines development and hypertext in a somewhat novel way.
>> >=20
>> > As for the notion of source you use, it'd be useful to give=20
>> an explanation
>> > of the reason for using sequences as your code shape;=20
>> perhaps by explaining
>> > what the sequencing is supposed to mean semantically, you=20
>> (we) could arrive
>> > at a better understanding.
>> >=20
>> 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.
>=20
> 'Application object'? This word connotes for me CORBA and COM and all sor=
ts
> 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.
>=20
The application of a function or a macro to arguments. I'm considering
using PyLisp's ingenious method of getting first-class macros:
functions are just macros that evaluate their arguments early.

> [Snipped stuff about persistency.]
>=20
>> > About multi-arrows, I'm not sure what kind of reference=20
>> this would be,
>> > perhaps you just need a collection primitive, and this is=20
>> your intent. Am I
>> > off?
>> >=20
>> A multi-arrow is conceptually something like this:
>>=20
>>                               x   y   z
>>                               ^   ^   ^
>>                                \  |  /
>>                                 0 1 2
>>                                 \ | /
>>                                  ---
>>                                   |
>>=20
>> 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.
>=20
> 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 'evaluation=
s'
> of the multi-arrow return the values successively? If that is so, then it
> would be equivalent to a stream ADT.
>=20
No. Evaluating it returns the first value; using some kind of macro
could allow one to extract what it points to as a list, etc.

>> You are off; multi-arrows are *not* collection primitives. They are
>> intended to be used as multiple values of sorts.
>=20
> Unfortunately, the multiple values idea only seems to come across as the
> same thing that most programmers call streams. Am I wrong?
>=20
I think so; the idea is that a function can return a multiple value
(sic), and, if necessary, programmers can extract all values out of a
multiple value, but otherwise only get the first one.

> Well, overall it seems you're mostly interested in re-interpreting and
> clarifying what Ted Nelson's Xanadu was trying to do.
Not anymore. Now I'm much more interested in figuring out the
semantics of arrows. Hypertext is easy and simple; arrows and 'verses
are difficult.

> Just keep working on the concepts and try to relate them to whatever
> existing abstractions you can.
The problem is that there is, for the most part, *no* existing
abstraction other than a locative in ZetaLisp or a pointer in C. The
only other thing that is even comparable is Lisp's continual emphasis
on object identity.

> 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.)
>=20
[looks around]
What has Far=E9 written about meta-text systems? Where can I get the
papers? Googling for metatext a few weeks ago (Far=E9 had mentioned it)
didn't find much...

> Keep at it...
> ~
>=20

--=20
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