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.