An Apple tech note says:
The AEBuild* suite of routines provide simple to use and easy to maintain facilities for constructing complex Apple event structures in memory for sending information to other applications. AEPrint provides a symmetrical pretty printer routine for viewing complex Apple event structures as strings formatted using the same syntax as the strings AEBuild* is able to read.And later, more explicitly:
When AEPrintDescToHandle is asked to print an AEDesc, an AERecord, or an AEDescList, then the format of the printed output will match the input expected by AEBuildDesc.Similarly, in the API docs, Apple says:
AEPrintDescToHandle prints the contents of AEDesc, AERecord, and AEDescList descriptors in a format that is suitable for input to AEBuildDesc. AEPrintDescToHandle also attempts display coerced Apple event records as the coerced record type instead of as the original type. Any data structures that cannot be identified are displayed as hexadecimal data.Don't be fooled, though. It's a pack of lies. I was writing some tests and took this at its word, thinking I could just make slight modifications to the AEPrint output. Indeed, however, if you feed AEPrint output back intp AEBuild, it will fail, because the AEPrint output is broken severely. In just one simple test with an object descriptor record, it's easy to see some of the problems:
print AEPrint(AEBuild(q['obj '{ 'want':type(prop), 'name':'prop', 'from':'null'(), 'seld':type(sdsk) }]));
# <- 'obj '{ 'want':type(prop), 'name':'prop', 'from':'null'(), 'seld':type(sdsk) }
# -> 'obj '{ 'want':'prop', 'name':'prop', 'from':''null''(), 'seld':'sdsk' }
The first thing to notice is the difference between type(prop) and prop. By default, the string would be taken as an enum (as the docs note), so it is coerced to a type in the former. But according to AEPrint's output, those are enums, not types. That's a run-time error. Similar too for type(sdsk). So while AEPrint "attempts (to) display coerced Apple event records as the coerced record type instead of the original type," it fails.
The other thing which is just crazy is the double-single-quotes around null. That's a compile-time syntax error (which is helpfully placed in $@, as: Expected "," or "}" at character 53).
There's probably more, as my tests are pretty inexhaustive. One more thing to note, though: AEPrint will truncate binary data (rendered in hex, such as ($DEADBEEF$)) if it gets too long, so it's one more reason you can't just feed back the AEPrint output to AEBuild.
I also can't find out how floats are supposed to be passed in. The docs say I can do float(@) and pass in the float as an argument (AEBuild works sorta like sprintf), but that doesn't seem to work. Nor does passing integers in as arguments (such as long(@)), although for those, I can include it literally in the format string, instead of passing it in as an argument.
But, as those problems having nothing to do with the Intel port, it's time to move on, for now.