Fare's response on threads
Lynn H. Maxson
Mon, 18 Sep 2000 11:19:18 -0700 (PDT)
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
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
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
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.