It appears that certification entries could use short annotations when they are made. That way we can find out why ESR is a Dimwit, for instance, or why others like him. Then again, perhaps it will be meaningless information, as everyone will just lie or skip the annotations part anyway.

apply(Master) ;; Best sex I ever had.

Also, I'd like to respond to some things in the byte-order thread, but 1) I am apparently not qualified to, and 2) There doesn't appear to be any way to respond to other comments, so they seem disconnected. Anyway:

nether writes about an amazing type interface that handles everything and is powerful. Well, everything except functions and objects. It also doesn't appear that it will handle dynamic structures or symbols, but that's hard to say without an implementation. It's not that hard to make up yet another set of names for unsigned ints, the hard part is handling functions, objects, and dynamic structures. If you've designed an amazing type system without these things, you probably need a redesign.

Several people suggested using text files. Text is good for smallish things, but 1) It inflates most data types, 2) It's difficult to write real numbers precisely, and 3) It's slower to read and write if you have huge amounts of data (Conversion to strings is even slower than byte swapping and unpadding data).

My recommendation: Use whatever formats are already standardized, if you can. CORBA is big and clunky, XML is text and is big and clunky, etc. However, portability is more important in the long run than nearly all efficiency concerns. Also, my experience has been that if you start to implement a cool new type system, you will end up with all this cruft anyway.

As an aside, it might be useful to have a byte or wyrd or whatnot that describes the format of a binary file, particularly temporary ones. That way you can implement simple ones as:

memmap(file, somewhere);
if (NATIVE_FORMAT != fileformat) {
  maybe_swap_bytes(somewhere, scratch); 
  maybe_unpad(somewhere, scratch);
}
if (swizzling_needed_p(somewhere) {
  swizzle_pointers(somewhere);
}

Since most of the time you will be running the program locally, the formatting changes will fall through anyway. It's not clear where to stick this information though.. It should be out of band so you don't have to copy all your memory to make room for it before you blast a file out to disk or across a network. Also, not every object needs one, just one per file or group of files. NATIVE_FORMAT can be used for network connections.