From: ·············@my-deja.com
Subject: Reflection?
Date: 
Message-ID: <9443lc$ni2$1@nnrp1.deja.com>
         From time to time I see references to "reflection" as one of
the most revered features of Lisp. What exactly does this mean? Is it
the fact the lisp code is lisp data or what?  O:-)

TIA


Sent via Deja.com
http://www.deja.com/

From: Kent M Pitman
Subject: Re: Reflection?
Date: 
Message-ID: <sfwhf2y2sb8.fsf@world.std.com>
·············@my-deja.com writes:

>          From time to time I see references to "reflection" as one of
> the most revered features of Lisp. What exactly does this mean? Is it
> the fact the lisp code is lisp data or what?  O:-)

It's related to this, but it's not really the same thing at all.

Lisp isn't really fully reflective (or sometimes we say "introspective")
but is more reflective/introspective than most other languages.  (There
have been designed some truly reflective dialects of Lisp, but they are
not used today.  They were mostly a theoretical exercise.  The dialect
I'm most thinking of is one called 3LISP, written by Brian C. Smith as
his PhD thesis quite some years ago at MIT.  It spawned a number of shorter
papers by others thinking about the general topic, and the terminology has
continued.)

Reflectivity or introspection is the process of trying to describe what
a program is doing, computationally, while it is executing.  Even a compiled
program must be interpreted.  But what interprets it?  Another program.
Can THAT program be described?  Yes.  How?  By talking about another program.
Can THAT program be described?  Yes.  And so on.  As many layers out as you
want to go, you can describe what is sometimes called an infinite reflective
tower.  In practice, you eventually ground out to something which merely does
something and which is not actually executing a program, but in theory you
can still introspect into that object.

In practice, or perhaps I mean just "statistically" (except I don't have the 
statistics), there isn't a huge amount of call for introspective nature
except in a few specific circumstances.  The places that are common to want
it are things like the following:

 - When loading a system, it's often useful to be able to view the 
   environment into which code is being loaded as data in order to
   be able to modify it to gain a better foothold.  For example, suppose
   you are loading into an environment where a particular functionality
   is required.  You may want to test that a certain function is defined,
   and if it's absent you may want to load an extra module.  Or if a certain
   buggy version of some function is present, you may want to unintern the
   symbol and make a new symbol that works better; doing it this way could
   be better than merely reloading the function since other modules are not
   affected--others may not agree with your assessment of what's buggy.
   Anyway, while gaining a foothold, a lot of Lisp programs manipulate their
   environment.

 - When entering the debugger, or trying to avoid it, you may want to 
   manipulate elements on the stack by treating the stack as data itself
   using some system-provided mechanism.

 - When a program is failing, it may want to consult its own dynamic state
   to see if there is an outer point to which it could usefully transfer.
   Common Lisp calls such points "restarts", and they are like throw tags
   except there is enough information attached to them that you can ask
   whether they are present without actually transferring to them, so you can
   decide among several possible ones, for example.

So this is all similar to the question of lisp program being data in
the sense that it's useful to find that Lisp programs are data when
reasoning about programs.  However, it requires more than that.  The
mere fact that Lisp code is made of symbols and conses is not what
enables you to manipulate the Lisp package structure as data.  It is
the choice here and there all over to provide functions that
manipulate the environment or the execution state of the running
program that are really the reflective aspect.  And, like functional
programming or object-oriented programming or other things, it's
really more a style or a mindset or an abstraction--it's not something
that is unambiguously present. It's like a view or an abstarction on how
you think about what you're doing.

Hopefully this is helpful.  I daresay the papers written on this topic
are a lot more lucid, though I don't know how easy they are to find.
I'm sure I have some in my file of hardcopy papers somewhere if
they've gotten lost.  I wish more people would be putting old hardcopy
papers online so they don't get lost before they (the authors, I mean)
die or the publishing institution loses them.  I've been trying to do
that with mine...
From: Marco Antoniotti
Subject: Re: Reflection?
Date: 
Message-ID: <y6citnedtcb.fsf@octagon.mrl.nyu.edu>
Kent M Pitman <······@world.std.com> writes:

> ·············@my-deja.com writes:
> 
> >          From time to time I see references to "reflection" as one of
> > the most revered features of Lisp. What exactly does this mean? Is it
> > the fact the lisp code is lisp data or what?  O:-)
> 
> It's related to this, but it's not really the same thing at all.
> 
> Lisp isn't really fully reflective (or sometimes we say "introspective")
> but is more reflective/introspective than most other languages.  (There
> have been designed some truly reflective dialects of Lisp, but they are
> not used today.  They were mostly a theoretical exercise.  The dialect
> I'm most thinking of is one called 3LISP, written by Brian C. Smith as
> his PhD thesis quite some years ago at MIT.  It spawned a number of shorter
> papers by others thinking about the general topic, and the terminology has
> continued.)

Just to remember old friends, some people at the University of Milan
(not me) did take the 3Lisp approach and built an interesting mix of
Lisp and Prolog using the notion of "reflective tower".  I can dig out
the reference if anyone wants (it was IJCAI mid-late 80's).

Cheers

-- 
Marco Antoniotti =============================================================
NYU Bioinformatics Group			 tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                          fax  +1 - 212 - 995 4122
New York, NY 10003, USA				 http://galt.mrl.nyu.edu/valis
             Like DNA, such a language [Lisp] does not go out of style.
			      Paul Graham, ANSI Common Lisp
From: Eric Marsden
Subject: Re: Reflection?
Date: 
Message-ID: <wziofx6p7ed.fsf@mail.dotcom.fr>
>>>>> "kmp" == Kent M Pitman <······@world.std.com> writes:

  kmp> Reflectivity or introspection is the process of trying to
  kmp> describe what a program is doing, computationally, while it is
  kmp> executing.

this isn't exactly the usual terminology used by people working on
computational reflection today (introspection is only one aspect of
reflection).

A reflective system is one which can observe and modify its own
behaviour and state. A reflective system is composed of a baselevel,
which corresponds to the normal functional aspects of the system, and
of a metalevel. The metalevel receives information about the behaviour
of the baselevel (execution of methods, access to variables, for
example) through reification, and can explicitly request information
(such as the value of a variable) through introspection. It can also
modify the state or the behaviour of the baselevel through a process
called intercession.

Reflection is a nice way of implementing non function properties such
as security or fault tolerance in a non intrusive manner. For example,
you could provide communication security by trapping all network calls
at the metalevel and encrypting/decrypting the data, transparently to
the baselevel.

Most reflective languages provide a clear separation between metalevel
and baselevel code, which is not present in Lisp. There are very rich
introspection mechanisms in Lisp, and stuff like advice lets you do
reification and intercession.

-- 
Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>
From: Reini Urban
Subject: Re: Reflection?
Date: 
Message-ID: <3a65cb5e.2967923378@judy>
I'm not quite sure about the right terminology so I try to ask with
examples:

(defun fn1 (arg)
  (fn2 arg))

(defun fn2 (arg)
  (format "called by ~s with ~s" 
          *reflective-caller* *reflective-args*)))

(print (fn1 'test))

package and classnames or class inheritence tree are probably easy to
get.
but I'm seeking for the actual function name, the given args and what
type of return value the caller expects. (multiple values, type)

interesting would also be the current stack frame depth, full access to
the stack frame, if any. the filename and linenumber, if stored.
most lisps have such stuff, but only internally.

perl has caller and wantarray in the standard.

   ($package, $filename, $line) = caller;
or ($package, $filename, $line, $subroutine, $hasargs,
    $wantarray, $evaltext, $is_require, $hints) = caller($depth);

are there better reflective features, besides restarts?

Eric Marsden wrote:
>>>>>> "kmp" == Kent M Pitman <······@world.std.com> writes:
>  kmp> Reflectivity or introspection is the process of trying to
>  kmp> describe what a program is doing, computationally, while it is
>  kmp> executing.
>
>this isn't exactly the usual terminology used by people working on
>computational reflection today (introspection is only one aspect of
>reflection).

-- 
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: Paolo Amoroso
Subject: Re: Reflection?
Date: 
Message-ID: <fuplOlMENKtfWbOl1Gb=Gjw=hOn7@4ax.com>
On Wed, 17 Jan 2001 13:59:07 GMT, Kent M Pitman <······@world.std.com>
wrote:

> Hopefully this is helpful.  I daresay the papers written on this topic
> are a lot more lucid, though I don't know how easy they are to find.

This definition: "_Reflection_ is the ability of a program to manipulate as
data something representing the state of the program during its own
execution" is taken from section "Reflection" of the paper:

  "CLOS: Integrating Object-Oriented and Functional Programming"
  R.P. Gabriel, J.L. White, D.G. Bobrow
  CACM, Vol. 34, N.9, September 1991, page 29

The paper is available online to ACM Digital Library subscribers, but a
reasonably well stuffed computer science or engineering department's
library should provide the journal.


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Tom Breton
Subject: Re: Reflection?
Date: 
Message-ID: <m3lms9al0z.fsf@world.std.com>
·············@my-deja.com writes:

>          From time to time I see references to "reflection" as one of
> the most revered features of Lisp. What exactly does this mean? 

That's not exactly true.  Reflection is where the code modifies its
own interpreter, often on a line-by-line basis; the so-called "tower
of interpreters" model.  See the language Refci for an example.

-- 
Tom Breton, http://world.std.com/~tob
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.