Arrows n=m+1 example

[RE01 Rice Brian T. EM2]

> On Mon, 26 Apr 1999, RE01 Rice Brian T. EM2 wrote:
> > i'll clarify on the issue of atomicity.  arrows are atoms of information
> (i
> > posit), so that when i refer to atoms, i imply arrows with unknown
> > semantics.  in other words, i am unconcerned with the arrow's references
> or
> > with the graphs that reference that arrow.
> 
> But you can also reflect on the arrow, which means taking into account the
> graphs that reference the arrow.  In this case you aren't considering that
> arrow as an atom. Am I right?
> 
yes, sort of.  the arrow is one thing.  the concept it represents to some
other part of the system is another.  that part is provided by some
"interpretive" (not the right word for computer science, but close enough)
structure.

> I'm working on the draft.  It makes a lot of sense.  I'll have to follow
> up soon
> with comparisons to my system.  For now, though, I'm positive each system
> can be represented inside the other.  The main difference is that Arrow
> makes no restriction on what arrow can point where, while (my unnamed
> system) has a strong type system always in effect.  You can achieve
> unrestricted combinations by defining a type that behaves that way.  I'm
> sure it is easy to add type restrictions inside Arrow.  I'm not sure if
> you would want to, though.
> 
representing each system within the other:
i'm very confident that it is possible.  whether it is desirable, i don't
know.  time should tell.

type restrictions in Arrow:
this is a very strange combination, since Arrow doesn't restrict anything
implicitly.  i did this half-intentionally, but i am beginning to be
comfortable with the results.  you really have to _tell_ the system that you
want to stick with a context (or any part thereof).  (you can even give the
system _rules_ about contexts, and reflect on them.)  the reason is that
there simply are no errors to make, only new contexts (sometimes a hell of a
lot and sometimes undesired).  in this way, i've learned not to think about
errors, but instead to try and focus on the desired information state of the
system.  it's an interesting view on information sharing, since in the new
way of looking at things, a cleaner (more well understood) division between
contexts is desirable.  that's because the shift between contexts is the
focus, and it has to work even if you remodel your view(s) of the system.
this provides an ideal system for translating information (i.e. meaning)
between two independent domains.

> > what atomicity means for arrows is that they have no "internal"
> structure at
> > all. this re-expresses the notion that the arrow system has no
> primitives.
> > instead, all information is external to the arrow, in terms of graphs of
> > arrows that refer to that arrow.  the current context merely decides
> which
> > of that information is important to mention and which is to be left
> > implicit.
> 
> I call the "graphs of arrows", expressions containing a reference to an
> object.  But there isn't much practical difference.
> 
there might be.  graphs can be re-used just like arrows, so that
relationships between things can be shared and morphisms can be drawn
between graphs and sub-graphs and cross-graphs(?) in any direction.

i'd also like to add that what defines a context can actually _choose_ among
the relationships that apply to an arrow those that it considers important.
this is an aspect of an ontology: whether or not certain kinds of
information translate to the target domain in a meaningful way, or
constitute noise.

you could even have an entire hierarchy (ugh) of types implemented in this
way, using a single arrow with graphs describing its properties and the
properties of its subtypes.

> > and, YES, the arrow system CAN be re-defined in terms of other types of
> > atoms.  the paper outlines a few ideas for centering the arrow context
> > around other ideas than the arrow construct and then interpreting arrow
> > information into these new contexts.  in fact, the entire system could
> be
> > implemented in other systems, given a certain meta-structure that is
> > arrow-definable.  i will get to this soon in explanations.
> Well, isn't that what you meant by model-level reflection, after all?  :)
> 
oh.  well, yes.  i also meant that the arrow system's models of itself and
others are never absolute.  oh wait.  i just restated myself.

> > circularity of definition is NOT bad.  take a look at the notion of the
> > relativism of ontologies.  an axiom of infinity _could_ be the ultimate
> > protection against deadlocking due to infinite loops.
> I agree it's not bad. That's what I said in my message.  How does the
> axiom of infinity work?
> 
oh.  it's just a simple logical assumption that is very useful to modern set
theory.  you basically assume that a first-order (finite) logic can assign a
semantically unique symbol to the number of natural numbers ("aleph sub
nul", or something like that).  logically, you can then analyze algorithms
and mathematical objects to see if they can be computed, if they _never_
will be computed, or if they describe nonlinear or chaotic systems.  you
even can derive the higher-order infinities, and prove things about them.
of course, some of these properties are undecidable (unless other logical
styles prevent this, but i don't know), so that deadlocking is then avoided
by conservatism and human assistance.

> > as for mathematical basis vice common-sense, i can see no other way to
> > provide formalized semantics or even approach a proof of the system's
> value
> > to Tunes.  natural language is just not going to provide you with the
> > necessary concepts.  for instance, try explaining the ideas of general
> > relativity to the laymen, and then compare his/her understanding to
> someone
> > who understands the mathematical proofs and equations and the physical
> > experiments behind the idea.
> Or we could implement a system.  Demonstration is a good way to explain
> things.  What code do you have so far?  I know you've worked a lot on this
> paper, but you said you had modified my tunes.c a bit.
> 
demonstration:  yes, as long as someone else (the implementor or theorizer)
understands it at a level that provides its vitality.

code:  it's not heavily modified.  what i did was to define a data-structure
format to describe messages from the user, and have the program read those,
while representing them as strings on the console.  parsing helps in the
other direction.  i also managed to get the persistent store to work, and
ported it to basic win32 APIs.  i don't want to continue with this, however,
until i've thought very well about the direction for the implementation to
go, whether to focus on graphics or basic context-shift mechanisms.  i'm
also trying to figure out what the arrow system would need to "know" in
order to achieve basic reflection (like shifting infinite structures'
implementation from the VM to arrow-code).  so i paused on that about two
months ago.

> > i hope you all are getting the hint by now, because its obvious that you
> are
> > still discussing the arrow idea on your own grounds, where only
> confusion
> > and semantic arguments propagate.
> What IS obvious is that a lot of people I have talked to (Fare included)
> are having difficulty understanding the paper.  I might like to try to
> write a guide to reading the arrow paper.  Would you support that?
> 
most certainly, and it would help with the introduction that i obviously
need to derive from this paper.  (i'm thinking about renaming this one "The
Theory of the Arrow System" and making a new "Introduction to ...").  don't
forget that drawings and examples are still in the works.  a week or so
should allow me to finish them.