Fare's response on threads

[Lynn H. Maxson]

Allow me to use a single response to mulitiple received.  I hope 
to do so in an order and manner which on "reflection" makes sense.

First, Frank Schmidt (in a private response) discusses an 
arrow-like system he is developing in C++.  He inquires about "... 
Primitives can be used as a method of mutating the system, and can 
be added or removed. I'm not too far into implementing it though, 
I still need to research what kind of primitives I will need for 
the most flexible solution."  If he were asking me I would tell 
him my source for such a decision: APL2.

Therein he will find a set of primitive functions and primitive 
operators which will challenge his use of C++.  However, these 
functions and operators are machine-independent primitives.  Their 
use in any environment depends upon their translation into 
machine-dependent primitives, otherwise known as an instruction 
set.

Alan Grimes should note that a machine instruction set is a 
functional language, representing the "primitive" 
(machine-dependent) functions upon which to build any hierarchy of 
machine-independent functions.  If you use a language to develop 
from a single system (source) applications for multiple systems 
(target) without having to recompile their source on the target 
systems, then you need to have the ability to translate 
machine-independent primitives into multiple machine-dependent 
ones.  As a developer I would want a language that gives me the 
ability for such a translation.

Now Jecel thinks I am reading too much into what Fare writes about 
"refection" and "reflexive systems".  He supplies the following:
"As for "reflection", we don't mean anything very deep by it. Only 
that the system includes a model of its own inner operation and 
can change that operation. We are not worried about intelligence 
or conscienceness. Only about having low level "knobs" in our 
design so it can better adapt itself to different operating 
conditions."

In my original response I was somewhat facetious when quoting from 
a once-popular country and western song in the USA:"I was looking 
back to see if you were looking back to see if I was looking back 
to see if you were looking back at me."  You see, that's 
reflection.  Moreover it is a multiple level reflection following 
the "comic" script used in the movies: "I knew you would say that.  
I knew you knew.  I knew you knew I knew. ...".  

As I said this is a particular "human" activity.  While we can 
"mimic" it in software we cannot forget that software only "does" 
what it does without, one, any "knowing" of what it is doing, and, 
two, if without knowing then completely without "understanding".  
Thus we may "mimic" human processes in software, but the software 
itself has no means of nor interest in doing so.

Now Jecel mentions a "model of its inner operation".  The question 
becomes is that a single-level model representative of a single 
level of reflection?  Or is it possible to offer multiple levels, 
a hierarchy of reflections?  If we can, then what determines what 
multiple?  Without limit, as we have illustrated in sci-fi films 
to defeat the "monster system", we can effectively trap in in 
reflection as its only work and in effect "destroy" it.

Obviously if a language offers reflective capability without some 
form of implicit (implementation-defined) or explicit limits, then 
it becomes part of the "use" of the language in an application.  
Now you see we not only have a metric for reflection in a language 
(presence, absence, limit) but also one for its use instance in an 
application.  This provides in turn an extended metric to include 
not only the language but its possible uses, i.e. what you can do 
with it.

However, I have problems with "model of inner operation".  Most 
readers of this have no working knowledge of PL/I, which is 
perhaps the powerful programming language available, as well as 
none of IBM's flagship mainframe operating system, MVS, again 
perhaps the most powerful operating system available.  MVS uses 
"reflection" of its "behavior", i.e. the aggregate behavior of its  
processes, to engage in dynamic priority scheduling of processes 
to maximise throughput.

In truth MVS does not do this.  It only mimics the reflective 
process implemented by its authors.  Perhaps the dynamic profile 
of an executing process constitutes an "inner model", but the 
statistics recording the dynamic process behavior are only "inner" 
withing the MVS system itself and not within the processes.  Maybe 
MVS does have a dynamic inner model of the executing processes 
upon which "user-directed" reflection occurs.

You end up with the possibility of a hierarchy of reflective 
processes, which are not a language but enabled by such, each one 
reflecting upon its contained processes.  The question remains to 
where does this reflection stop?  Does it occur only for the 
machine-independent processes or does it extend to the 
machine-dependent ones, i.e. to the ability to actually modify 
instruction sequences.  In short what are the limits on this 
"model of inner operation"?

You see it's not that I make too much of reflection, but it is not 
clear from either Fare's or Jecel's usage with respect to Tunes 
where it begins or ends.  Fare may prefer fuzzy definitions.  I 
have no problem with that as long as in specific instances we can 
get the "fuzz" out.

If we agree that software can only "mimic" reflection, then the 
authors of such mimicry must provide an operational definition 
either through a set of boundary instances (relationships) or 
algorithms (rules).  These in Prolog terms constitute a 
specification.  I would think that we could write such a set for 
the Tunes HLL requirements.  If we cannot, then we should 
seriously question them.