Replies to replies.

[RE01 Rice Brian T. EM2]

>> But isn't total reflection a goal?  What's so wrong about giving the
>> user the option to destroy the system?  Naturally, we wouldn't like that
>> to happen, so what we could do instead is to restate the ontology to
>> make the question (to kill Tunes or not to kill Tunes?) seem unnatural.
>> This ties in to my conception of how to get the system to do things on
>> its own in a reflective way.  We could 'encode' the identification in
>> the object system of the 'actor' of the system with the mathematical
>> 'core' of the system, so that it would inherently include as one of the
>> partial-evaluation constraints (axioms) the preservation of this aspect
>> of the system via preserving reversibility of partial-evaluations.  I
>> should clarify and add to this, but I'm at some sort of loss for words
>> right now.  Criticism is welcome on this point.
>Surely there is no Tunes without total refleciton. The question is
>whether or not it is possible to get ther in one go, and if not what
>would be an intermediate stage? Incremental development is nice in
>theory, but it has traps. During development your always faced with the
>possibility that choosing an easy way at an early stage will make
>development at a later stage difficult or even _impossible_ ( its always
>possible getting there but some times it's just as well starting all
>over again ). So even though you are implementing the system
>incrementally, you need to have a mental picture of the finnished system
>in order to avoid these problems. And you'll have to decide upon a
>"path" of implementation - where to start and so on ... eventually
>coding yourself into a corner in the ceiling:)

Maybe there's a difference in the value of incremental development
within Tunes and incremental development leading to Tunes, due to the
nature of the substrate (object system vs. a programming language like
C).  I think that the "mental picture of the finished system" is
inherently _not_ something that we can develop without knowledge of what
our current mental picture does for the Tunes system.  In other words,
just as I said earlier about the use of words constraining this
development, so also will the development of a "mental picture" will
inherently never be what we will want in the end.  The situation seems
to be such that any mental picture that we get will be quite the
"static" view of Tunes, with terms variously interpreted.  My argument
is to build some concrete system to reason about in a first-order way,
so that we know exactly what things we can construct and what the
context needs to provide to construct more complex things.
A bit of confusion, I think, also arises from the use of the word
"implementation".  Coding ourselves into a corner is a real and
dangerous possibility, and should indeed be avoided.  What probably will
happen is that the entire C source will have to be completely re-thought
for even minor extensions.  My goal for the scheme to write the code for
the machine model is to take an abstract specification, such as "the
context provides object representation support for such-and-such types"
or something like that.  Achieving that goal is the point of my current
thread, and I _do_ seek help.

>Anyone ever worked for days on a piece of code and manage to loose it?
>Writing it again is always much much easier, and the result far better
>then the original code. Because you have a better understanding of what
>problems you'll have to face.

Sure, but I want the source code to be quite uncomplicated and
un-optimized to ease the writing of code that fits the machine model's
desired characteristics.

>I don't see how the reflection is going to enable the system in doing
>things "on its own" that is not just as possible in, say, BASIC. Please
>explain.

Well, there are logics which describe how procedures (or functions or
whatever) can be expressed as things like information-state updates or
downdates, or as data-flow diagrams.  The machine (object system) should
be able to invoke procedures in some sub-system with an understanding of
what that will do to it.  Otherwise stated, the machine should be able,
through user-added decision schemes, to construct procedures as
evaluations of desired information-updates.  This is what I mean by
having the system do something on its own.  In Basic (or any other
extant programming language), for example, the ability to encode such a
system of procedure-logic would be nearly impossible for the average
programmer, and a great difficulty for an expert.  Automation is an
extension of mapping desires to contexts.  In computing machines
(finite-state machines), the problem set must be reduced to some finite
group of evaluations (calculations) in order to achieve this.
What I'm looking for is a Tunes-level generalization of the main loop
construct, I guess, where automation is guaranteed by not "leaving" the
loop.