Arrow system

[RE01 Rice Brian T. EM2]

> [ snip ]
> > ok.  the "shifting" of contexts was supposed to relate to the papers by
> John
> > McCarthy called "Formalizing Context (Expanded Notes)" (i lost the URL,
> but
> > i'm sure that the tunes site has it somewhere).  so that related to
> > interpreting information gained by one computation for the use of
> another,
> > unrelated computation.
> > the searching problem, as you state it, is another issue.  i think that
> the
> > solution could be found by a simple idea:  suppose we take some
> data-format
> > (a state-machine algebra) and define its information in terms of arrows.
> it
> > should be easy, then, to store most of the arrow system's information in
> > terms of that data structure, based on the efficiency of the encoding
> > (information density, search-and-retrieval times, etc).  we could then,
> for
> > instance, store information in syntax trees (like LISP) and retrieve it
> in
> > the same way, constructing arrows for the information iteratively.  this
> > could even allow us to gain new information from, say, Lisp or Scheme
> source
> > code.
> 
> I'm not sure I get it. You want to create a state-machine that, the same
> way one can check the presence of e.g. a string, check the "presence" of
> a valid system state? It sounds too simple, but it's an interesting
> idea! Are you sure you wouldn't need to build a new machine for every
> request?
> 
actually, i'm sort of _interested_ in building a new machine at every
request, but also in having the system be optimized for doing so.  with
arrows, their graphs can be used to build state-machines, possibly infinite
in size (which means that abstract language models can be built).
of course, the idea of having state-machines dynamically instantiated on
request begs that we use partial evaluation and persistence to create these
earlier, such as when we define the data-format to the system.  then the
question is where to place this information and how to re-use it
effectively.

> > > Now, where I'm getting at is: What kind of computational model do you
> > > propose? ( that is: how will the system in practice process requests
> > > like "what is n?" ?) It would be interesting, in the context of arrows
> > > beeing a very general form of data organisation, to see what
> complexity
> > > it would have, and what compromizes ( if any ) and restrictions ( if
> any
> > > ) it would have.
> > >
> > in this case, i would generally propose lambda-calculus, which is
> acheived
> > quite readily by the arrow system when you make category diagrams.
> category
> > diagrams are just arrow graphs where all arrows compose sequentially.
> the
> > arrows represent lambdas, and the nodes represent expression types.
> > otherwise, i believe that ontologies and algebras could help to define
> any
> > execution scheme that a person could imagine, even complicated ones.
> 
> If I understand correctly, then arrows in their raw form must be
> interpreted in some context. E.g. when you say above that
> lambda-calculus can be achieved by regarding the arrows as those in a
> category diagram. Other examples are object diagrams to model the state
> of a system ( how the actual instances of things are connected together
> ), and state diagrams to model the transitions between different states
> in the system.
> 
> I think this is where coloring of arrows, as June Kerby talks about,
> comes in. In that scheme, you would say that a category diagram style
> arrow is one color and a state transition style arrow is another. In the
> general case, you would need one mother of a pallette. I guess you
> wouldn't want coloring in your model, but still the problem of "what
> does the arrow connecting these two enteties mean?" must be addressed in
> some way.
> There is however an alternative to coloring, that better fits the style
> of your model, and that is contexts, saying that the color of the arrow
> is dependent on the situation.
> 
yes, and if you replace "color" with "meaning", then you'll find a somewhat
complete answer in the arrow draft. (sections 2.2.2, 4.6, and 4.7, i
believe)

> But there are some problems with this that you might not want. First of
> all the "situation" is dependent on the evaluation of something and then
> you need context switches - but these context switches, beeing all
> arrows, need some meta context switch in order to apply the proper
> interpretation. And there will be _alot_ of context switching.
> 
the arrow context switch could be contained by a single graph, or most
likely a multitude of graph structures in order to provide a framework for
reasoning.

> The second problem ( I personally see this as a property and not a
> problem, but I know Brian is against hierchies ) is that contexts,
> always working on homoiconic arrows ( no coloring ), eventually end up
> forming a hierchy. I.e. one context, formed by the area of switch-on to
> switch-off, _must_ be contained fully inside or fully outside any other
> context.
> Imagine contexts 'S', for "legal state transition", and 'C', for "is in
> the same category as". I'll denote a context with labled parenteses,
> i.e. '(C' and 'C)'. Small letters are things to be interpreted. Now, if
> I say:
> 	(C a (S b C) c S)
> 
> Then, given that the system is homoiconic, there is no-way to give any
> meaning to 'b'. Choosing to view 'b' as talking about state transition,
> gives you a 50% chance of failure - it's ambiguous.
> 
yes, but then you're proposing the "push"/"pop" model anyway, which suggests
a stack immediately.  if you view it another way, then context-shift
designators "(C" and "C)" enclose an ordered pair "(a,b)", which an arrow
could represent.  likewise, the state-transition designators "(S" and "S)"
do the same for "(b,c)".  by placing these graphs under the appropriate
deterministic logic, meaning _can_ be derived, but it is really two
completely separate meanings instead of a necessarily singular meaning.
now, those two meanings _might_ be contradictory, but that would depend on
the ontology: on how you decided to interpret what C and S meant in a given
context.  of course, if "b" is an atom in a context, then the
interpretations of C and S should not be at the same order of abstraction in
order to avoid the ambiguity.

also, i'd like to relativize any concept, such as S="is a legal state
transition".  i'd like to place that in an environment (like Tunes) where
generalizations can be readily made in a semantically clean way.  my idea is
that perhaps what passes for legal state transitions in one system means
something completely different to another system or context.  perhaps one
acts as the machinery for the other, so that state transitions become parts
of operators.  or maybe the ontologies completely crosscut each other, so
that it's hard to express verbally what the difference is.

> If, on the other hand the system was not homoiconic, i.e. two different
> types of arrows, then one can imagine that 'C' effected another type of
> arrow then 'S'. That could work, but there would be inpureness or
> sideeffects, and code would need to be veryfied at a level prior to
> reflection - and you don't want that.
> 
> Conclusion ( please flame me if I'm wrong ) : In a homoiconic system,
> the need for interpreting information dependent on context, enforces
> some hierchical property on the system.
> 
i don't agree, of course.  just take a look at the draft.  you'll see that
it describes contexts as identifying agents (i mean all the aspects of
agents that you would want to apply) with structures of ongologies called
"ontology frames".  the frames are basically collections of nodes in an
ontology graph, overlaid by a structure that i haven't looked into yet.  the
idea is that a context has a boundary, and that interpeting information from
the outside of it requires some translation process from an exterior
ontology to one of its own ontologies (represented by an arrow).  within the
context, perhaps the translations should be computable and completely
defined, but that seems unnecessarily strict, since they should / could be
used to build those transitions.

the big idea, i think, is the use of a graph of ontologies with information
interpretations between the ontologies as nodes.  this graph will most
certainly contain higher-order infinities of nodes as well as translations,
but should be managable.  the intention was to get around the strange
properties of set theory, but the applications may be much wider in scope
(i'm guessing).