tunes-0.0.1.c

[RE01 Rice Brian T. EM2]

> I like the approach of arrows.  A graphical approach should work.
> 
yeah, it should allow terminal-independent representations (text vs. bitmap
displays) and serve to increase the user's intuitive grasp of the system's
workings.  however, i can imagine cases where a single structure would have
lots of arrows pointing to it or its parts, and the user would wish to
'factor' these arrow into groups according to their conceptual purpose.
this factorization could again be achieved by other arrow structures which
point to those groups, but then we obviously want this added structure to be
'invisible' as a first-order representation, so that what we would really
want to have would be a 'flavored' interface, with various contexts to allow
this 'embedding' of arrow structures into the interface metaphor.

> How will you define the semantics of an individual arrow?  In terms of
> other arrows, I assume?  You will have unlimited levels of nesting of
> "arrow spaces"?  If you don't know what I mean, please ask and I will
> clarify.
> 
yes, but i'm still not sure how to use the idea of 'context' in encoding
semantics using arrow structures only.  and nesting arrow spaces is
something which goes hand in hand with knowledge-level reflection and the
creation of new contexts, so honestly i'm not sure yet how to do this,
although i have some ideas which are still vague.  i'd like to hear some of
your thoughts on how to do this.

> The only way I know to represent infinity is by recursive functions (in
> your case, an arrow, where the space defining the meaning of the arrow
> contains a reference to the first arrow).  You can define infinity by an
> iterator function, that produces N arrows in a pattern, where the given N
> required by the function must be finite, but the *type* of N is boundless.
> Does this make sense?  This description was also very brief, and can be
> expanded if you need examples.
> 
recursion, iteration, ...
it amounts to the same thing.
one thought that i had on the subject, besides the 'axiom of choice' idea,
was that the problem is essentially equivalent to encoding the description
of the system (like the natural number system) in an arrow-structure, and
then have the c-program come up with "examples on demand", basically by
denoting the number desired in a first-order or meta-order way (by direct or
indirect specification).

> > i haven't had much time to think about this recently, but that has
> > changed, possibly permanently, within the last day or so.
> If you want to have a dialectic then I'm game.  I'll try to keep up with
> you!
> 
cool!

> > btw, if anyone knows of a better interface for maintaining object
> > references in the system i am describing other than by explicit pointers
> > (or just as complicatedly, by graphical-arrow representation), then
> > please share the idea, since my system as it stands will require lots of
> > searches or lots or reference-counters for a garbage-collector.
> The question shouldn't be "is there a system to maintain object references
> dynamically."  The question is, "does the complexity of the system I am
> developing make up for itself in the expressivity gained?"  The idea is an
> extraordinarily complex system will make up for its own complexity, if it
> is reflective.  (i.e. the complexity can be used to index itself.)
> In other words does YOUR system of arrows and nodes provide sufficient
> expressivity to support the functionality it needs (maintaining object
> references).  If so, then you're set because as long as your system is
> reflective it can use its own features to implement itself.  That's just
> my theory.  It's not supposed to be easy to DO.  ;)
> 
yes, i've thought of it that way at times, and i agree.  i _do_ like the
sentence about "the complexity being used to index itself".  maybe that's a
metaphor we can grow on.