[BBF Standards] Amorphous languages for bio fabs

[Jake Beal]

> Very interesting indeed. Thanks for the links. But I am somewhat 
> confused about the proposed compiler tool chain. I'll give a more 
> thorough read over the PDF soon. I gave this general topic some more 
> thought this morning, and was unfortunately offline, but now that I am 
> back on I have decided to throw up my notes on a wiki, but since they 
> are so very informal I have placed them over at biohack instead of OWW:
> http://biohack.sourceforge.net/wiki/index.php/Biobricks#2008-02-20

The key idea is the separation of the problem into loosely coupled
layers.  The amorphous medium abstraction and Proto language bridge
the global-to-local gap, making it easier to design distributed
algorithms for a spatially extended systems like an embryo.

In the end, though, the language does not "solve" the problems of
robust distributed assembly.  Instead, the global-to-local bridge
sweeps aside much of the routine work of distributed programming, and
imposes a discipline that prevents accidental mixing of levels.  In
our experience, this makes it easier for the programmer to grapple
with robust assembly problems directly, and to trust that the
solutions they find are likely to generalize well and compose nicely
with one another.

In this framework, creating an appropriate toolkit for robust
distributed assembly is an exercise in library building, rather than
language design.  But, of course, the difference between those two is
just a matter of perspective, especially in the eyes of a LISP hacker.
:-)


The real problem that we face in moving to the higher level components
you describe, like "OrganBricks," is not how to build them, but how to
describe what is the thing that we actually want.  Take, for example,
the "make skull" command from the example in your Amorphous Compilation
section.  What does it mean to have made a good skull?  

All animals use approximately the same skull-building program, and it
is clearly not made by a CAD-style blueprint, for it changes too
easily to accomodate other changes in the structure of the organism.
Unless we have a standard for comparing skull-building programs and
knowing which ones are better, we cannot debug our ideas about
skull construction.  The questions that we need to consider include:

* How is the shape of the skull determined?
* How should the location of holes in the skull be determined?
* How should thickness relate to head size?
* What sort of flaws are OK?  What sort of flaws are bad?
* How should the skull change as the organism grows?
* How should the skull respond to flaws in constructing nearby parts?

The answers to these questions will tell us much of what we need to
know about how to write a spatial program that builds a skull.  The
advantage of a language like Proto is that we can expect a high
percentage of code to be derived directly from the answers to these
questions.

Thanks,
-Jake