Re: ObjC dynamic parser

[Marcus G. Daniels]

>>>>> "GR" == glen e p ropella <address@hidden> writes:

GR> I can also imagine adding special purpose languages that
GR> might only be used by certain objects (like S-expressions for GP,
GR> conceptual graphs for comp. ling., or raytrace descriptions for
GR> graphics evolution).

In the case of GP, I think it is a mistake to use a "special purpose
language".  

On pg 707 of:

@Book{koza:book,
  author =       "John R. Koza",
  title =        "Genetic Programming: On the Programming of Computers
                 by Natural Selection",
  year =         "1992",
  publisher =    "MIT Press",
  address =      "Cambridge, MA, USA",
  keywords =     "genetic algorithms, genetic programming, text book",
  ISBN =         "0-262-11170-5",
}

John Koza warns:

 "The second reason for defining problem-specific functions is that
  each function in the function set must be well defined for any
  possible value (or type) which it might encounter as a result of
  taking as arguments any terminal of any value that might be returned
  by any function in the terminal set.  For example, the ordinary LISP
  division function / should not be in the function set of this symbol
  regression problem because of the possibility of a division by zero."

But it doesn't need to be like this, and it especially doesn't need to
be this way in Common Lisp, where there is a rich object-oriented
facility for defining and trapping exceptions; it isn't necessary to
strip the world to down to some milquetoast relatively fit subset, if
the programming language actually has the notion of death.

So rather than thinking in terms of `sum of its parts', let the 
fitness computation include the notion of `does it work at all?'.

Specifically, rather than:

 (compute-fitness-across-cases program)

where `program' is composed of slow, dumbed-down functions like:

 (defun protected-divide (numerator denominator)
   (values (if (= 0 denominator) 1 (/ numerator denominator))))

one can instead use the native `/', and bailing out (to whatever desired
degree) of fitness testing after a class of failed computation, e.g.:
 
 (handler-case (compute-fitness-across-cases program-object)
               (division-by-zero () -1))

Of course, Common Lisp isn't the only language with exception handling --
Java has it too (although Java lacks the nice code-as-data quality that
Lisp has).  Another attractive language for GP is ML.  ML is useful
for GP because `dead' computations can be identified at compile time by
type analysis (in a dynamically typed language you have to wait around
for them to happen).

My point is that thinking of GP as nothing more than S-Expressions
(presumably building on some simple parsing mechanism) will
reduce the space of feasible problems relative to using rich language
substrate.  And so long as a rich language substrate is wanted, it
might as be available for all kinds of programming.

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================