Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a

[Andy Wingo]

On Thu 10 Nov 2011 17:46, Mark H Weaver <address@hidden> 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/