Arrow system

[Thomas M. Farrelly]

"RE01 Rice Brian T. EM2" wrote:
> 
> > > > 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)

I'll look at it.

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

And these context switch graphs would have what color?

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

Two things:

First of all, you constantly try to solve the context switching problem,
with new graphs of different color. Eventually you will end up needing
an additional framework around your graphs of an increasing complexity
as you get closer to your ideal flexible system. You can call this
framework an ontology or whatever - the point is that it will impose
restrictions of the form "It is pointless to interpret some graph under
some ontology, because the ontology it was created under needs to
encapsulate information ( in static contexts ) in order to keep the
graph interpretable, or the other way around so that it will be
missinterpreted".

Imagine this. You have something describing the state transitions in an
automata. Under TUNES it would be possible to do whatever you wished,
and the lucky wish is: Put some system state invariants on the whole
model, like "this and that state is to take maximum 1 second". So now,
when going form one state to another, the system will sometimes test if
the time spent in the last state is within a special interval. And if
you wanted to, go to a special state depending on this.

In the arrow system, you say that state transistions can be expressed
simply by a graph of the transitions, but when you want to _add new
information to it_, as it often the case in a reuse situation, it
suddenly is no longer interpretable by the same ontology - and there
need not be information available to create the new ontology from the
old one. This means that it is not very easy at all to communicate the
different graphs between the different ontologies that initially all
talked about the same concept.



It appears to me ( who is by no means an expert ) that you have
reinvented the usefullness of references. But you lack real objects to
reference. Surely you can call the definition of objects for ontologies,
but it doesn't help much. It will not provide any uniform way of
interpreting information. It's close to saying: "lets interpreted all
information as bits!", "what about [fill in problem here] ?" - "I'll
just use some more bits for that!" - and we all know how that went:)


Flame me if I'm wrong, or give me a concrete example of how something
real can be done. For example:

	a = b

 
===============================================================================
    Thomas M.  Farrelly     s720@ii.uib.no     www.lstud.ii.uib.no/~s720
===============================================================================