On Sat, 21 May 2011 06:20:28 -0400, Andy Wingo <wingo-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote: > I think that Guile's needs are different here. I need to be able to > allow distributors to release a new Guile binary package without causing > recompilation of user libraries. Of course this requires some care in > maintenance, so as to only make compatible changes, but the trivial case > of recompilation of an unchanged source package should produce a > compatible binary package. Okay, that's an interesting and worthwhile goal. I wonder if it wouldn't still be possible to do this while not providing the same guarantees to users who produce code that would break this compatibility. For me, the major problem in thinking that one can maintain ABI compatibility in the presence of procedural macros is that, in general, you can't. Even code that has absolutely no source changes can potentially change from expansion to expansion. Moreover, this does not even take into account how the compiler might interact with compiled code. Taking your example, where you want to be able to release an ABI compatible binary package for Guile without requiring user's to recompile their own user libraries, I'll shift this over to Chez, since I know more about how Chez works. This simply wouldn't be possible to do in something like Chez Scheme, even if it did allow leaks at the top level. When you compile, for example, and R6RS top-level program, Chez takes advantage of having a total picture of the code to be compiled and can inline it's own code from the core (chezscheme) library into the user's code at optimization levels greater than, say, zero or one. If another release of Chez Scheme comes out, ABI compatibility now means much more than just making sure that all the names match. It also means that all the source code that may have been inlined, must now also remain unchanged or observationally equivalent at the very least. These sorts of problems crop up all over the place, and it is difficult to actually achieve ABI compatibility in the presence of these problems, so Chez does not even try. I would be interested in knowing what tradeoffs Guile makes in order to guarantee the ability to have ABI compatibility between compiles, given that in the general case this cannot be guaranteed even if the source code never changes. Aaron W. Hsu -- Programming is just another word for the lost art of thinking.
