On Thu 10 Nov 2011 17:46, Mark H Weaver <m...@netris.org> writes: >> 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. > > This is certainly a compelling reason. Nonetheless, I find this loss of > hygiene extremely disappointing.
Me too. But this is a tradeoff. It is entirely unacceptable to have a situation in which a user installs Guile version 2.2.0, compiles some Scheme package Foo against it, then downloads Guile 2.2.1 and installs it, causing breakage because the .go files from Foo encode the unique names corresponding to the compilation of Guile 2.2.0. > What you have implemented here is not Scheme, but rather something > that looks like Scheme and claims to be hygienic, but will in fact > break hygiene in many plausible cases. This statement galls me to no end. I don't even know how to reply to it. I have written and deleted many paragraphs here, but I think it would be best if you sent another mail that examines the ramifications of both sides of this issue. I might have made the wrong choice, but your proposal does not do the problem justice, not to mention the four days that I spent on fixing it. Andy -- http://wingolog.org/
