Re: [Scheme-reports] Are generated toplevel definitions secret?

["Aaron W. Hsu" <arcfide@x>]

On Sat, 21 May 2011 06:20:28 -0400, Andy Wingo <wingo@x> 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.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports