Loading ...
Sorry, an error occurred while loading the content.

1424Re: [GP] GP, meta programming and reflection

Expand Messages
  • Mariusz Nowostawski
    Mar 2, 2003
    • 0 Attachment
      Tom Lenaerts wrote:
      > Metaprogramming can be defined as the art of programming programs which
      > 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.

      This is quite an accurate statement about meta-programming, however
      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
      > 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?


      "Meta-programming" in GP
      ==================================

      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:
      http://www4.informatik.uni-erlangen.de/Projects/PM/Java/publications.html
      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 [1] 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 [2],
      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.



      [1] 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.


      [2] 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
      capabilities.
      Similarly with Push (no offense Lee): the language is not reflective in
      the proper meaning of the term.



      --
      best regards
      Mariusz
    • Show all 6 messages in this topic