languages that might be used

first - very very basic commands for creating and deleting and listing. not
much more useful than a ject, really. designed for loading most data from
supplied dna file/object. may also need file/object to get non-dna properties
from; stuff that would normally come from mother. first meant as a prototype
language; may be useful for bootstrap or something.
2) parts language. includes the creation thing. may have different sets for
organic/electronic. not sure how restricted it'll be. will mostly be concerned
with transforming chems & other vars, and interacting with the world via body.
3) agent language. caos-like language for admin-type stuff, designed for
manipulating the world however user wants. generally for kits that connect to
the engine. not designed for heavy math or anything; they should do that
client-side. it's more of a get/set thing.
4) dna language. also may be different for organic/inorganic. would probably
be binary file kinda like creatures dna.
5) neural net stuff. may end up being inside parts or dna language. out of scope
right now; need a world before we can have brains.

urgh. that's too many languages! but for now I only need to worry about 1,
then either 3 or 4, and perhaps a bit of 2a later.

1 already has ls, add and del - will just have to improve syntax of add.
3 could be hard... depends how much I shift off to the client. might end up
being pretty simple. at minimum it'll need stuff like get, set, import,
export, new, kill...
4 will be very tricky when I have to think about mutation - but for 4a I can
hack together something simpler. just enough to describe the bare minimum
first, a few little vars. not sure if it should have strings.

also, at some point when the thing has users I may need restrictions on what
they can do. for a private game it doesn't matter but for a multi-user server
it would. I'll probably also need a hand agent of some sort...

oh, and as for part files, dna files, etc... should I leave htem just on disk,
or cache them in memory, or what? I'll want to get dna from other objects as
well as from files... and might want to save dna from dead creatures, but not
from everything (that goes into the whole history thing I think). also not
sure how often I'd be reading hte dna... or writing it, for mutations. I
suppose that either the cobs would store their own or have pointers to a
cache. so I'd have to have dna in memory at least while it's in use. machines
may be able to share, copy-on-write perhaps... storing many mutations of dna
for simple common critters may be annoying so hopefully their dna would be
short.

so I guess I have a reference to the dna in the cob. but as a pointer, a
filename, a char*? since I'm only reading hte dna at creation right now, I
might as well just dump the filename in there... heh, that's assuming dna
created by breeding does get written to file. whatever, I can always change it
later.

oh, but that means passing a filename not just a number... ehh... absolute
paths certainly should not be used. probably the dna should just have a simple
name, and the function for getting it should read the appropriate file if
necessary or something.

of course, this probably means that every dna thing ever must have a unique
id. some sort of dna fingerprint would be mostly-unique, but you could still
have two the same by accident. living dna could be uniquely identified by the
object it's in, but when you want to load new dna, say for an injector or
bootstrap... feh, actually you don't need any 'unique' id worries, if you
don't mind having the same dna duplicated a few times. dna must always be
contained in *something*, either an object or some archive or a file. that
should be good enough.