Re: GP/lisp question

[Marcus G. Daniels]

>>>>> "MM" == Matthew M Murphy <address@hidden> writes:

MM> Depending on the particular functions that an agent has access to,
MM> the interpretation of the information may differ, or the
MM> information may be uninterpretable.  The goal is to evolve a
MM> homogeneous class of functions that serve the interpretive "needs"
MM> of the agents, as well as to evolve the arguments (the data)
MM> according to the functions that have been selected.

MM> It occurs to me that perhaps a language such as ML would also work
MM> well for this kind of thing.

Cool!

Hmm, all depends whether you whether you want to be a liberal or
conservative parent to your [agent] kids.

The Lisp parents hover over their kids, planning contingencies for all
the bad things that might happen (say, using a flexible
object-oriented exception handling system like CLCS), and the ML
parents would make lots of rules and hire nannies, etc. (inventing
flexible but rigorous type systems).

With 2.0, making Lisp or ML agents work with Swarm should be within 
reach for the minimally bloody-minded.  (..I'd love to work on this
stuff, but I can't justify taking the time to do it.)

Ideally there would exist a Lisp or ML implementation with a
tightly-integrated Objective C interface (I'm not aware of any).
However, there are several simple libraries that do transparent
conversions between Guile (a Lisp implementation) and the GNU
Objective C runtime.  The GNOME project has URLs to some, IIRC.

A minimal from-scratch approach would be to write a small Objective C
library that had a few C functions for configuring and running
schedules.  You'd need to write some argument conversions to extract
and create objects for each [language] side.

In the case of Guile, there's a C API for creating and destroying Lisp
objects, etc.  In the case of a system like CMU-CL, there's a Lisp API for
setting up calls dynamically from Lisp; you describe the calls and it
creates dynamically generates native code stubs.  Anyway, you'd
probably end up with a simple C support library and then either frozen
or dynamic stubs to glue Swarm to the language implementation.

The trickiest part is making outgoing messages to foreign agents talk
back to Swarm -- message forwarding in Objective C is a
moderately violent business.  Luckily 2.0 will provide portable
message forwarding code that can be used to take apart an Objective C
call.  With this capability (which we needed for Java) it's easy to
take apart and re-issue Objective C calls.  For Lisp, it would be
especially easy (you don't have to describe what you are doing -- you
just start pushing the objects you want on the stack and call the
[generic] function).  For ML, there would probably be some Java-like
call setup typing.

Once you had Swarm and your GP environment talking, the next thing is
deciding to what extent it is important that agent state can be seen
and acted upon in both environments.  It might well be that there
isn't really a need for much interoperability, i.e. agents mutate and
recombine in predefined transactions, and Swarm just coordinates the
transactions.  On the other hand, if you wanted to evolve schedules
and Swarms, so a few kinds of non-trivial transparent conversions could
be very useful in some contexts.

Note that if you have a small, fixed vocabulary of actions that
is well-behaved, you might want to try to organize
evolution in terms of dynamic scheduling instead of executable
data structures.  E.g. looping maps to setRepeatInterval:, and
the executive managing generations is like an `experiment Swarm'.
A plus would be that it would be self-contained in Swarm.  A minus
would be that it could be especially hard to visualize the algorithms that
evolved (e.g. we have no `activity' serialization capability yet).

                  ==================================
   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.