guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mark H Weaver
Subject: Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a
Date: Tue, 15 Nov 2011 22:58:44 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Andy Wingo <address@hidden> writes:
>> 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, for what it's worth, I have enormous admiration your work.  You
are a powerful force for good in the world, and it makes me glad that
you have chosen to put so much of your effort into promoting free
software, GNU, and Guile.  You are truly one of my favorite people.

Please keep that in mind when reading the criticism which follows.
(I should probably stop here, but alas, I'm a stubborn bastard ;-)

Even if the tradeoff you chose were justified (which I do not concede),
I believe that you handled this commit improperly.  In your message to
the scheme-reports list, you clearly described what you did, were honest
about the lack of hygiene, and admitted your uncertainty about how best
to handle this thorny issue.  That honesty was admirable.

Unfortunately, those important facts and caveats were not evident on
this mailing list, nor in the commit log, nor in the comments of your
code, nor in the Guile manual.

The unconventional heuristic you chose (which violates hygiene as
mandated by the Scheme standards) is not documented anywhere in git that
I can find, nor is it obvious from a casual perusal of the code (at
least not to me, who has never taken the time to understand psyntax).
It was never discussed here on guile-devel, and apparently even your
co-maintainer didn't know.

The commit log claims that the new code "hygienically rename[s]
macro-introduced bindings", which is simply not true.  You swept some
embarrassing caveats "under the rug", so to speak.  If I hadn't posted
my skeptical query, we might have believed that syntax-case and
syntax-rules were now hygienic.  It makes me wonder whether you have
done this kind of thing in other commits.

I believe that this criticism is warranted regardless of whether your
unusual approach was justified.

>>> 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.

I think there are better ways to address this problem.  I will explore
these in another email.

     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]