Arrow diagrams

[RE01 Rice Brian T. EM2]

> Why have arrows?  Aren't arrows just functions?  An arrow to an arrow
> should be a function to a function.  You're just talking about
> higher-order functional programming.
> 
Ahhh, yes.  But with a difference!  Functional programming would fail to
handle the logical inconsistencies suggested by the statement, "what is true
here should not be true there."  What I mean is that this system should play
with context in a way to make the word 'paradox' meaningless.
Of course, here we're talking about recursive functional definitions which
may turn out to create infinite (non-returning) loops or even uncoountable
structures.  The arrow structure syntax should allow the versatility to
sidestep these questions by, for instance, representing these loop
structures as arrow graphs and having the arrow graphs accessible as
arguments for some analysis algorithm with (for the loop structure author)
an arbitrary semantics.  This might allow, say, topological algorithms to be
applied to something which ordinarily would not apply, like using
graph-coloring to allocate resources (like processor registers).