1424Re: [GP] GP, meta programming and reflection
- Mar 2, 2003Tom Lenaerts wrote:
> Metaprogramming can be defined as the art of programming programs whichThis is quite an accurate statement about meta-programming, however
> can read, manipulate or write other programs. A typical example are
> interpreters. These are programs which are able to manipulate and
> reason about lower level programs. In most cases, the interpreter is
> referred to as the meta-level and the program is at the object level.
the comment about interpreters is not really true. For some languages
and some interpreters it may be the case that we deal with
meta-programming, but this is not always the case. Not all
interpreters can "manipulate" programs and not all programs can
"manipulate" their interpreters.
One can look at interpreter/program as an example of
meta-level/base-level relationship, but this is stretching the
definition. I am not sure which was your main objective, so I will
briefly address both of the topics.
> Since GP is all about the evolution of programming, it seems logical"Meta-programming" in GP
> that one would like to evolve combinations of meta programs and object
> programs to solve problems. I was wondering whether this issue has been
> recognised before in GP. I assume it has yet i'm not aware of any major
> contribution in this context. Can somebody provide me with a pointer?
> If this has not been recognised before, can anyone explain why it might
> not seem relevant for a GP system?
We deal with meta-programming when we have the notion of base level,
which is "manipulated" or "reasoned about" by meta-level. "Manipulated"
is not precisely defined. It is accepted to understand it as full
structural and functional reflective capabilities, i.e. retrospection,
reification and introspection. Programming languages are referred as
capable of meta-programming if they are capable of structural and
functional reflection See for example:
for some articles about building meta-programming environment in Java
for Java (MetaJava).
Indeed, it is very interesting idea and could be applied to GP or other
evolutionary system. I think, that the main reason for this idea to be
somehow neglected and that is not really present in the literature is
its complexity. The capabilities offered by meta-programming
environments are so complex, that even human programmers need special
training and paradigm shift to be able to use them effectively. I
strongly believe though, that eventually all our evolutionary code
generators will be fully reflective. And that future generations of
evolutionary computation researchers will wonder how we could go for so
long without it. At the moment however, we do not know exactly how we
could deal with the complexity offered by meta-programming paradigm.
I would be interested myself hearing about others working in
meta-programming evolutionary systems.
"Interpreter/program" relationship in GP
Interpreter/program relationship, again, has very interesting
implications in GP and code generation. Again, it is not widely used
notion in GP-like research. I can speculate that the reason is probably
"field boundaries": evolutionary computation community and theoretical
computation community are probably forming two quite disjoint sets ;o)
"Interpreter/program" notion naturally forms a particular ordering (or
organising) relationship, which may be used to describe a particular
hierarchy of levels of organisation. See  for details about
organising relations in respect to emergence and hierarchies. In context
of evolving programs in general (as already pointed out by Lee) Push
system can be one of the examples.
I have discussed the idea itself and its implications in details in ,
where I have used PushGP system as one of the (ideal) examples. I am
working on more formal formulation of this notion, and would be glad to
hear others using it as well.
 S. Jones. Organizing relations and emergence. In R. K. Standish, M.
A. Bedau, and H. A. Abbass, editors, Artificial Life VIII: Proceedings
of the Eight International Conference on Artificial Life, pages 418-422.
MIT Press, 2002.
 M. Nowostawski. Hierarchical code generators. In E. Blotta, D.
Gross, T. Smith, T. Lenaerts, S. Bullock, H. H. Lund, J. Bird, R.
Watson, P. Pantano, L. Pagliarini, H. A. Abbass, R. K. Standish, and M.
A. Bedau, editors, Artificial Life VIII: Workshops, pages 63-72.
University of New South Wales, Australia, 2002.
ps. One should keep in mind two different meanings of the term
"reflection". The more formal meaning of this term is different from its
common use. Java is not formally reflective language, even though
marketing departments are selling it as reflective. To be fair and
precise, Java is retrospective language, with some retrospection
Similarly with Push (no offense Lee): the language is not reflective in
the proper meaning of the term.
- << Previous post in topic Next post in topic >>