specs

[RE01 Rice Brian T. EM2]

> >>  - how is the number of slots significant?
> >it signifies positive statements that we make about what the abstract
> object
> >"is" (which is, of course, relative even within the system).
> 
> Ah.  Like a Folder in Zope (www.zope.org) -- all Folders are identical,
> but they become different when you put stuff in them (including other
> folders).
> Except that Arrows have a fixed number of possible references.
> 
not necessarily.  if we have something that modifies multiple-reference
arrows so that it essentially "pushes" a new reference onto the arrow, then
we would have the appropriate idea for "changing" the type of a particular
arrow.  really, this is all arbitrary:  i could have made arrows
de-dimensionable, and then later explained how to reflect on this system by
postulating "static" arrow states where the re-dimensioning action was made
explicit.  also, there are obviously a multitude of ways that we might want
to change what an arrow is, including its type, so that making one method
implicit would be restrictive syntactically speaking.  (witness the
concatenation of lists in Lisp- every other method of making lists in Lisp
is a combination of these fundamental operations.)

> Okay.  And the 'type' of an arrow is essentially the same as its dimension
> (sure, it's a different number, but big deal).
> 
right. there's an isomorphism there, and i could perhaps have used the same
indexing system for both to make the isomorphism implicit.

> No problem about iteration, although I don't see how you're going to solve
> any real problems that way.  This is FAR too abstract to actually
> implement, at least as described.
> 
i'm not sure about that.  if we remove the restrictions for finiteness and
include some abstraction mechanisms (i haven't yet determined the
requirements for this set of abstraction operators, although i don't forsee
any problems in that direction as long as we discuss the various methods).

> Unless all you want is a gesture -- well, here you are: (define (arrow
> head tail) (cons head tail)).
> 
that would allow us to use Lisp to simulate the arrow system, but the
limitations of Lisp might be cumbersome for some of the things i would lilke
to express in Arrow.  maybe it could be used for a portable description of
graphs or something.

> >the main new benefit is arbitrary
> >cross-cutting of ontologies _without_ the invocation of any special
> >reflection method.
> In the vulgar tongue, you can slice theories of knowledge in half.  Sounds
> ... unique.  Doesn't sound useful, unless you're a really agressive
> debator.  I'm joking, but I'm serious that this sentance doesn't mmake any
> sense to me.
> 
well, in current systems, the only way that you can reference something
posited within the system is to have an identifier for it, and make an
assignment.  the arrow system allows you to "reach into" any specification
and make it "your" first order object in your own algorithm.  similarly, you
can reach in and point to a pattern in some code you just wrote, or to
postulate a pattern that only exists across many specifications.

does that help?

[about being unclear in my explanations]
> I totally understand that.  I _always_ do that to my ideas, and my first
> posting is sometimes disasterously sloppy.  I'm _slowly_ learning how to
> really think my ideas through while I'm writing about them.
> 
i just wanted to add that i _have_ been able to explain my system to several
different people, it's just that the kind of expression appropriate for
doing so exceeds ascii text by a great deal, and i'm still working on some
diagrams for the language in some drawing applications that i have, so that
there may be some help soon in explaining this system.