simulator (Re: [Icfp04-discuss] three liberal arts)

[Andreas Bogk]

Alan Schmitt <alan.schmitt at polytechnique.org> writes:

> By the way, I'd be curious to know what people think their mistake was 
> during the contest (if they think they did a mistake). In our team, we 

We had some people in the team who started hacking ant strategies in a
quickly-hacked assembler, and then some who worked on a decent
macro-based language, and hacking strategies in them.

When it came to merging stategies (gatherer, defense, attack), we had
to do too many things manually, and in the end the time ran out to
properly debug things.

Our language actually was pretty nifty.  We used Dylan's macro
facility to come up with a syntax, which looked like this:

define sub brain test-sub(back)
         Move back => sub-problem;

  [sub-problem:]
         Drop, (back);
end brain;

This is basically a sub-routine that gets instantiated on every call.
The "back" symbol (in this case, or any arbitrary other one) gets
substituted by the symbol of the same name in the caller context.

The main routine looks like this: (no, it doesn't do anything useful
except illustrating syntax)

define brain test-brain1
  [start:]
         Set V1 = #t;
         IfSet (V1)
          { Drop, (fonz); }
          { Drop, (sub-problem); };

         Sub test-sub;
         Move fonz  => start;
  [fonz:]
         Sub test-sub;
  [choose:]
         Flip 3 => turn-right; // no-branching
         Flip 3, (turn-right); // yes-branching
         Flip 9, (turn-left, turn-right);
         Drop, (start);
  [back:]
         Drop, (start);
end;

Things of interest: 

* If the branch target is the next instruction, it can be omitted.
  Exception is at the end of basic blocks, you always need a branch
  target there.

* There are variables, which work by duplicating states, as described
  by others before.

The macros build a data structure of instructions, which almost look
like the ones understood by the simulator, except that branch targets
are represented by closures looking up the symbols in an environment
during flattening.

Nifty, but too late. :)

BTW: another argument for writing your own simulator: the ability to
produce execution traces with symbolic labels.

Andreas