Where Tunes is going.

[Brian Rice]

At 09:21 AM 10/22/99 -0700, David Hilvert wrote:
>On Fri, 22 Oct 1999, Brian Rice wrote:
>
>> It sounds like you've completely missed the point.  I'm suggesting
>> abandoning the *language* idea altogether as a model for Tunes, and you
>
>Hmmm... what do you mean by language?  

Well, there are many degrees of difference between Arrow and your basic
computer language.  For starters, the state of the Arrow system will not be
consistent or often decidable from every perspective.  For another, there
is no implicit 'symbol level' for Arrow.  You can take the complex
structures from one framework and treat them as atoms in another,
regardless of whether or not those structures represent computable things
or are themselves computable (as a reflective Lisp would require).  And
since Arrow should allow you to make graphs referencing collections of
arbitrary structures (infinitary, nondeterministic, etc. (let your
imagination run wild)), this ability exists at every place in the system
unless you specify such an appropriate limitation in the context.  I'm sure
that there's more, but the right explanation doesn't come to mind right now.

>> state support by proposing your Open Implementation *Language*.  That's
>> absolutely absurd.  Unless your language has no inherent semantic content
>> whatsoever, you're just feeding me the same nonsense that I've seen from
>> everyone else.  It sounds like you have the usual mis-interpretation that
>> assumes that Arrow is a language, and not a framework for abstracting
>> arbitrary information patterns.  I'll even go as far as accusing you of not
>> being able to distinguish Arrow from Lisp.  If you can't prove that you
>> understand the difference, then you merely re-inforce my point.
>
>Well, once you begin to describe such arbitrary information patterns to a
>system, you have created a kind of meaning, and it will be easier to
>express new patterns which are easily related to the old patterns than it
>will be to express new patterns which are difficult to describe in terms
>of the old patterns.  This is not a problem unique to computer programming
>languages.

Of course, but programming languages, not by being formalisms but by being
first order or restrictedly-reflective, intrinsically limit how far this
development of meaning via patterns can go.  As suggested above, I'd like
to remove these limits inasmuch as the hardware will allow, and please
trust my belief that the hardware can support a much better environment
than we have ever seen.

>David

Finally, I suppose that I should re-iterate why my explanations aren't
fantastic (but improving).  I learn from mathematical theory books and what
I develop in my own mind from the patterns I see.  I have no daily contact
with any programmers or mathematicians of any sort, and so my feedback loop
must run through this group.  It follows that you _will_ hear some crappy
explanations from me, along with some refined thought.  We as Tunes must
work through these ideas, because otherwise the product we eventually
present will be un-intelligible to others.
Keep in mind that I'm not discussing computational concepts.  There are
enough people to work on persistence schemes and computational models and
thread-management and kernel-less design requirements etc.  We don't need
to concentrate on that, because we can re-use all of their results and
documentation.  We have to focus on the essence of Tunes: how to provide a
unification scheme for everything that people do with computers.

Enough of the soapbox for now,
	Brian