Hello Aaron, Thanks for your reply. Re-adding the list. On Fri 20 May 2011 19:29, "Aaron W. Hsu" <arcfide@sacrideo.us> writes: > On Fri, 20 May 2011 04:29:49 -0400, Andy Wingo <wingo@pobox.com> wrote: > >> But then if you recompile a.scm, to a.so, you would have to generate >> the >> same gensyms, or b.so will fail to link when it is loaded later -- so >> the gensyms aren't quite random... > > Here is the crux of the matter. You want to be able to recompiled one > library and have it be ABI compatible with previous compilation > instances of the same library. Yes. > This is different than separate compilation. Separate compilation does > not mean that any one library can be recompiled without affecting > others, it just means that you can recompile them separately and at > different times. Hmm; ok. Let's call what I am interested in "compatible recompilation": see below. > More to the point, how does Guile determine that the ABI is not > compatible? I think this is an interesting question but not perhaps germane to my argument. My example has file A.so, and B.so which has been compiled against A.so. If I have not changed A.scm or any of its includes, loads, or imports (in short: its depedencies), and none of its dependencies uses procedural macros, then under any definition this should be form an ABI-compatible A.so -- at least, it's what I want. >> Back to the future: there is no issue in recognizing introduced >> bindings. That's fine. However when reifying these bindings to some >> compiled object, you have to give them an identifier (in some general >> sense), and that identifier needs to be stable to allow separate >> recompilation. How does one provide a stable identifier for something >> that's supposed to be unique? > > Your assumption is that they need to be stable in order to allow > separate compilation. They need to be stable only if you require that > you can recompile one library without ever needing to recompile the > other. In Chez Scheme, which does not have the top-level hygiene > problem, this is not the case. You can recompile files separately and > independently, but compiling library B which depends on library A > requires that you first have a single compiled instance of A on which B > can depend. This means that if you recompile A, and then try to use > that newly compiled A with an older instance of B which was linked > against a different version of A, you will get an error stating that B > expects a different compilation instance of A. > > I happen to think that this is a reasonable tradeoff; you may disagree. Thank you for this description, it was useful. 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. Causing B.SO to *rely* on an identifier that is generated anew every time A.scm is compiled introduces a coupling between compiled files that is invisible to the user, and is not acceptable in Guile's use case. Now, I could get around this issue by somehow explicitly specifying the names to introduce, or the seed for the gensym algorithm; but at that point you're hacking around a misfeature. Dunno, in short. Andy -- http://wingolog.org/ _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
