A small conceptual improvement in the Arrow theory and Squeak cod e

[RE01 Rice Brian T. EM2]

i'd like to update the conceptual situation within Arrow which i have been
developing to a fine degree lately: ontological relativism.  the issue
struck me as odd that self-referencing arrows in my private prototype's code
always result in deadlocks.  needless to say, i had to re-construct my
classes from a previous version, omitting (conspicuously) the NulArrow
definition (you know, it's the arrow that other arrows refer to solely when
they are nodes).  instead, it will merely be a user-level object within the
core model-reflective arrow logic description (a description of arrow logic
within the arrow system).  in other words, from that logic description's
viewpoint, that arrow will merely be the referendum of many "nodes" until
they become proper arrows.  this "root" seems a natural focal point for
system construction.  the question remains: 'what arrows shall this
(hopefully featureless) root arrow reference, if not itself?'  if i pick
arbitrary arrows within the system, i may generate non-sense arrow meaning
(think of arrows as Lisp CONS structures, and you will have the idea), which
would be a bug, to say the least.  i will get back to answering this in a
moment.  for now, follow the next train of thought, please.

this user-level implementation of the node root suggested a simple
generalization which answers a much earlier question about the Node type
within the system (whether to implement nodes as arrows).  i believe that
the answer is "yes", for the reason that all arrows are considered from some
viewpoint as nodes.  (for a specific quick example, consider the
set-theoretic meta-graph of any graph: its nodes are another object's
arrows.)  for this reason, i consider ontological relativism to apply to the
node concept as well.  so, consider all nodes to be arrows and all arrows to
be nodes.

all of this reasoning, ironically, immediately feeds back into the notion of
the Graph type, since it is the "simplest" construct to use nodes.  so,
although graphs are simple fundamental types, the question of "what arrows
represent graphs?" is again _relative_ to the ontology that frames the
question.

i was chewing on these ideas while debating the implementation direction for
the ArrowWorld class.  i had just changed the ArrowGraph implementation to
inherit from Arrow, so that the "root" of the tree for the set's meta-graph
would be available for first-order use without a special variable within
ArrowGraph.  you might say that the ArrowGraph _is_ that Arrow, while its
MetaGraph _contains_ that arrow as the root of the tree and the ArrowGraph's
elements as the tree's leaves.  in this way, the MetaGraph makes the
branches available for first-order use.

(here is where i answer the earlier question.)  it struck me then that
ontologies would be interpretable as graphs (thinking along the lines of the
mathematicians that tried to apply set-theory to everything), and that the
ArrowWorld itself would be a graph.  it therefore seems natural to have
ArrowWorld inherit its graph-like features from ArrowGraph in the same way
that ArrowGraph inherits from Arrow.  now, the SelfGraph variable is
unnecessary, and we have an environment that is conceptually very similar to
one of its first-order constructs!!  what i'd like to do is to shift
contexts (ArrowWorld's) dynamically, using this construct and a theory of
graphs and arrows at a first-order level within the system.  i am also
exploring the questions of how to implement "handles" for operating the
underlying implementation from within the system.  in other words, i'd like
to operationally model the underlying system and modify the implementation
to respond to system operations on that model.  (i leave the rest of my
thoughts to your imagination until i am ready to formalize them.)

anyway, many new results will follow from this, and i intend to document all
of it soon (most likely in a new paper).  i also have new ammunition with
which to help close out the original paper.  also, expect a new source file
to be released soon, with a nearly-fully developed set of classes.  i'm not
yet satisfied with my ideas on making an example system, so be patient with
that, please.

i hope that you all are as excited about these results as i am!  if anyone
has ideas or criticisms to contribute, they would be quite welcome!