reflection (was: Fare's response on threads)

Lynn H. Maxson lmaxson@pacbell.net
Tue, 19 Sep 2000 09:11:26 -0700 (PDT)


Jecel,

I'm sorry I couldn't resist responding with "my point exactly".<g>  
With that facetious remark out of the way let's get to the more 
serious discussion.

"But in a way, the program now "knows" where it was loaded in 
memory and what resources it is using."

I would almost respond that to know is to know you know, itself a 
reflective activity/process.  The "in a way" is part of the 
deceptive beauty of mimicry in that it leads us to engage 
improperly and incorrectly in "transference".  Reflection is a 
particularly (though not exclusively) human ability.  When we 
engage in it we are "aware" that we are doing so.  In fact it is 
that awareness that "inspires" to define it, to give it a "word".

Everyone reading this knows that a computer, a system of hardware 
and software, does not "know" what it is doing.  It only does it.  
It does it without knowing.  To date we have found no means of 
transferring our means of "knowing" to software except through 
mimicry.  HAL as depicted in "2001" is impossible.  It's bad 
enough when movies, books, press, TV, etc. engage in such flights 
of fancy, but we are supposed to know better.

Mimicry is a form of simulation.  Basically software simulates 
what otherwise would be a manual human activity.  Moreover it 
simulates only repetitive "clerical" activities which we "know" 
how to translate into the instuction set of a computer.  That says 
that we know there are things we don't know, again something not 
possible to "transfer" (currently) into software.

As long as we acknowledge that reflection (or reflexive 
programming) is based on mimicry I don't have a problem.  It isn't 
something that the software "knows" it is doing.  It is simply 
something that it does, moreover that it was told to do.  Mimic 
behavior then in software must be "externally" imposed, written, 
directed, or otherwise humanly expressed (directly or indirectly).

Reflexive programming then occurs through deliberate insertion of 
an human author.  To assert then that the "system" does this or 
that means that some human author has directed it to do so.  In my 
particular project in which a single language is used throughout 
(not because it is necessary or better but only that it is 
possible) I must insure the transition exists from my level of 
assertion throughout all lower levels.  In short I cannot assume 
that the "system" will do anything without having first "told" it 
to do so.  The telling of the first part must meld into that of 
the second: they must exist as a whole concurrently.

I do not have then the "convenience" of higher level abstractions 
without its lower level dependents.  Together they make up "the" 
system.  In short I do not have "this" system which uses "that" 
one.

My intent lies not in putting words into (or out of) Fare's mouth, 
but to caution that not all readers come equally prepared.  Thus 
when we talk of such things as genericity, et al they are not 
characteristics per se of the object, but controls that we have 
imposed upon it.  In meeting the Tunes HLL requirements then says 
more about what "we" have to do in order for the "proper" mimicry 
on the part of our product.