specs

[RE01 Rice Brian T. EM2]

> arrow.  really, this is all arbitrary:  i could have made arrows
> de-dimensionable, and then later explained how to reflect on this system
> by
> 
oops. read "re-dimensional". silly me.

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

ok. i should definitely clarify this.

the arrow system allows you to "reach into" any specification and make _any
_parts _of _it_ into your first-order object (etc).

the point is that you can now make statements (say, implemented as an arrow
whose meaning is known and whose slots are filled by the user) about
specifications (specifications of any level of abstraction) without regard
to what was chosen in the specification to be the explicit atoms and what
was chosen to remain nameless structure.  another way to put it is that any
invocation or reference anywhere is like an identifier in an ordinary
programming language in that you can refer to it from anywhere in the
system.

this idea is related to the inclusion of an algebra of context within the
arrow system for reflection, in that in order to access a context you have
to provide relations to it, and that accessing context is just like
providing a variable or procedure closure, or making a namescope a
first-order identity.

here's an example of a thought experiment i once was working with:

we take the standard block-structure language (like BETA) with clean
semantics and no pointer arithmetic, and we create a system with modules and
a command-line interface for accessing the environment.  in this system, the
usual "directory systems" and "files" are instead identifier-scope
hierarchies and sequences of statements which form a specification of, say,
a procedure or a data-structure.  i even went as far as to use the standard
'cd' notation with slashes, '.', '..' and such.  such notation was
integrated with the language itself, and one could imagine an entire
operating system with such an integrated scripting language.  even run-time
invocation of procedures (or methods if you're going for the object-oriented
style) and the resulting call stack structure would be accessible in this
scheme, with the exception of recursive loop constructs that explicitly use
procedures to do so.

(there's an extension that i played with concerning inheritence diagrams and
making such spaces accessible as a web which the programming language could
access by a very similar, but richer, notation.)

the point is that scope (a primitive context) was "made into" something
which could be accessed by reference, and was no longer unavailable as a
first-order object for manipulation and reasoning.  it was also seen that
such a system had 'roots' in common systems whose ontology many people have
found relatively intuitive.  the arrow system is my attempt at accomplishing
such a thing in a system-wide and in a manner independent of the concept
which the user wants to make available from the code.