>> And why would I do that? Because, presumably, I don't want to re- >> type the definitions of the library that are already included in a >> .h file, and I'd rather write a tool that can be used and re-used as >> the .h file changes, than have to fix things by hand. > > (That is a perfectly fine job for a macro, BTW.)
Parsing a .h file? Boy, I've written hairy macros in my life, but that's got to be a winner. >> As part of that pre-processing, it would examine all the >> identifiers, and report any conflicts. >> >> I doubt that there would be many if at all. > > So in the case I describe above, it will break... No. It will produce a correct output. >> And since pre-processing time is prior to actual use, I have plenty >> of time to handle any conflicts. > > ...requiring manual intervention. Even if you manage to specify sane > translation rules, you still need to choose those rules manually, and > you'll still need to inflict that pain on the people who need to cross > reference your bindings with the foreign documentation. IOW, nothing > new. Requiring manual intervention of the consumer of the changed library. Yes, that can happen when a library changes. But only if someone has introduced an alias for this particular case. Usually the least of your trouble. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
