The generation of artificial life is often needlessly hindered by forcing the alife to learn not only the correct algorithm to use, but also the correct grammar in which to implement that algorithm. The extra complexity of the grammar is much more difficult to learn, in general, than the algorithm used. A simple alife generator, for instance, might spew out random words and then feed them to a C-like compiler to see if they would be correctly compiled, and then if so run it and see if it does anything useful. Just getting the alife to spew valid code would be quite a task! Instead, it seems that alife that we wish to generate a valid algorithm should not be needlessly hindered by the additional complexity of the 'grammar'. Its language should be 1) conceptual and 2) parameterized (that is, it should have 'validity' parameters enforced). As an example, lets take an environment such as the old 'C-robots' arena-type battle programs. Suppose we wish to evolve a good combatant. Before we discuss metrics and the measuring of performance, we must turn our attention to the language that our alifebot will use. The bot should not have to try and generate valid C code, as that would be an unnecessary hindrance. Instead, the language it speaks should be more conceptual - one 'command-option' might be 'turn [-180 to +180] degrees'. This command is always valid. Note the [-180 to +180] degrees phrase. This is what I meant by a 'validity' parameter. It would make no sense to allow the robot to choose an arbitrary number of degrees to turn, since all directions are contained within 360 degrees, anything higher than that is superfluous, and inefficient. Note, however, that unnecessary parameters should be avoided as they have the effect of stifling the 'creativity' that we are pursuing.