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

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

[Mark H Weaver]

Hi Andy,

> commit de41e56492666801078e73860a358e1c63cbc8c2
> Author: Andy Wingo <wingo-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
> Date:   Fri Nov 4 19:34:22 2011 +0100
> 
>     hygienically rename macro-introduced bindings, reproducibly
>     
>     * module/ice-9/psyntax.scm (chi-top-sequence): Detect bindings to
>       identifiers introduced by macros.  In that case, in order to preserve
>       hygiene, uniquify the variable's name, but in a way that is
>       reproduceable (i.e., yields the same uniquified name after a
>       recompile).

What method do you use to uniquify a macro-introduced top-level name,
such that a recompile yields the same name?  I have doubts that this is
possible without breaking hygiene in some cases.

     Mark

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

[Andy Wingo]

Hi Mark,

On Thu 10 Nov 2011 05:36, Mark H Weaver <mhw@netris.org> writes:

> Hi Andy,
>
> What method do you use to uniquify a macro-introduced top-level name,
> such that a recompile yields the same name?  I have doubts that this is
> possible without breaking hygiene in some cases.

See http://thread.gmane.org/gmane.lisp.scheme.reports/896/focus=1009.

Andy
-- 
http://wingolog.org/

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

[Mark H Weaver]

Hi Andy,

Andy Wingo <wingo@pobox.com> writes:
> On Thu 10 Nov 2011 05:36, Mark H Weaver <mhw@netris.org> writes:
>> What method do you use to uniquify a macro-introduced top-level name,
>> such that a recompile yields the same name?  I have doubts that this is
>> possible without breaking hygiene in some cases.
>
> See http://thread.gmane.org/gmane.lisp.scheme.reports/896/focus=1009.

Thanks for the pointer.  For posterity, here's the relevant post:

> From: Andy Wingo <wingo-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
> Subject: Re: Are generated toplevel definitions secret?
> Newsgroups: gmane.lisp.scheme.reports
> To: "Aaron W. Hsu" <arcfide-5nC73gNclPNzbRFIqnYvSA@public.gmane.org>
> Cc: scheme-reports <scheme-reports-y6AJiVCXveJwtQyMDPLuwh2eb7JE58TQ@public.gmane.org>
> Date: Mon, 07 Nov 2011 12:30:22 +0100 (3 days, 4 hours, 45 minutes ago)
> 
> Hi,
> 
> On Tue 24 May 2011 23:10, Andy Wingo <wingo-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> writes:
> 
> >    (define-syntax define-const
> >      (syntax-rules ()
> >        ((_ name val)
> >         (begin
> >           (define t val)
> >           (define-syntax name (syntax-rules () ((_) t)))))))
> >
> > Guile currently does not make the generated toplevel definition "t" have
> > a fresh name.  It would be nice if it could but it can't be a really
> > random name -- it needs to be predictable.
> >
> > Well why not have the name of "t" be "t" plus some string which depends
> > only on the incoming form -- like its hash value.  (Or the outgoing
> > form; the considerations are different but similar.)
> >
> > That way you do preserve the "compatible recompilation" aspect, trading
> > off true secrecy, but hey.  Oh well.
> 
> FWIW, I have implemented this in Guile's master branch.
> 
>   > (define-const foo 10)
>   > t-798f2ffcb9d7f9 
>   $1 = 10
>   > (define-const bar 20)
>   > t-
>   t-1a0faae6e8559b31  t-798f2ffcb9d7f9    
> 
> Here I used tab completion to show me the available bindings.
> 
>   > t-1a0faae6e8559b31 
>   $2 = 20
> 
> The appended uniquifiers are derived from the hash of the stripped
> definition form, i.e. `(define t 10)'.  This means that there are still
> some situations in which two bindings will collide -- as in:
> 
>    (define-syntax define-variable
>      (syntax-rules ()
>        ((_ name val)
>         (begin
>           (define t val)
>           (define-syntax name
>             (syntax-rules ()
>               ((_) t)
>               ((_ v) (set! t v))))))))
> 
>    (define-variable foo 10)
>    (define-variable bar 10)
>    (bar 20)
>    (foo) => 20
> 
> I'm not really sure what the right thing is to do here.

You ignored what Aaron W. Hsu pointed out:

> I am interested to see if you come up with something that preserves this  
> capability while preserving hygiene. A straight hash of the input form  
> will not be enough, because the form could be evaluated multiple times,  
> and each time it would have to have a different identifier internally.

To be fair, you expressed the reason you felt compelled to do this
earlier in the thread:

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

This is certainly a compelling reason.  Nonetheless, I find this loss of
hygiene extremely disappointing.  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.

I think we should provide two variants of syntax-case, one that handles
secret top-level definitions hygienically (and given the standard name),
and another with a different name that uses your hack.  syntax-rules
should be based on the hygienic variant of syntax-case, but we could
provide a variant of syntax-rules with a different name that is based on
your hacked variant of syntax-case.  We could then use your variant only
where necessary, and document the tradeoffs between the two variants in
the manual.

What do other people think?

    Best,
     Mark

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

[Ludovic Courtès]

Hi,

Mark H Weaver <mhw@netris.org> skribis:

> Andy Wingo <wingo@pobox.com> writes:
>> On Thu 10 Nov 2011 05:36, Mark H Weaver <mhw@netris.org> writes:
>>> What method do you use to uniquify a macro-introduced top-level name,
>>> such that a recompile yields the same name?  I have doubts that this is
>>> possible without breaking hygiene in some cases.
>>
>> See http://thread.gmane.org/gmane.lisp.scheme.reports/896/focus=1009.
>
> Thanks for the pointer.  For posterity, here's the relevant post:

Thanks for digging it out.  Would be nice to see such Guile development
discussions on guile-devel, too.

Ludo’.

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

[Andy Wingo]

On Fri 11 Nov 2011 21:20, ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Andy Wingo <wingo@pobox.com> writes:
>>> On Thu 10 Nov 2011 05:36, Mark H Weaver <mhw@netris.org> writes:
>>>> What method do you use to uniquify a macro-introduced top-level name,
>>>> such that a recompile yields the same name?  I have doubts that this is
>>>> possible without breaking hygiene in some cases.
>>>
>>> See http://thread.gmane.org/gmane.lisp.scheme.reports/896/focus=1009.
>>
>> Thanks for the pointer.  For posterity, here's the relevant post:
>
> Thanks for digging it out.  Would be nice to see such Guile development
> discussions on guile-devel, too.

Indeed, though to be fair that was a thread that was months old, in
response to others' comments on the spec, and initially directed to
other implementors, after the threads we had here.

Andy
-- 
http://wingolog.org/

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

[Andy Wingo]

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

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

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> 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

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

[Andy Wingo]

Hi Mark,

On Wed 16 Nov 2011 04:58, Mark H Weaver <mhw@netris.org> writes:

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

I understand how you can perceive this.  The commit log should have been
better worded, but I was simply elated that it worked at that point.
Understandable, no?  I often update the manual and NEWS in separate
commits, sometimes very much later.  It's not ideal, but I do get it
done before the next release, so please, a little bit of slack, here.

> It was never discussed here on guile-devel

Ah, I thought that it was.  Instead I discussed it with the Scheme
experts over on scheme-reports, and with the bug reporter.  My bad,
there, I guess?

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

I look forward to this.  Please be sure to address the following issues:

  * Debian upgrading guile to a newer version, without recompiling
    guile-foo which depends on a hygienically introduced identifier.

  * A user modifying a Scheme file from Guile, in the spirit of the
    LGPL, and expecting it to work with program Foo, without recompiling
    Foo (again, in the spirit of the LGPL).

Regards,

Andy
-- 
http://wingolog.org/

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

[Mark H Weaver]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 16 Nov 2011 04:58, Mark H Weaver <mhw@netris.org> writes:
>
>> I think there are better ways to address this problem.  I will explore
>> these in another email.
>
> I look forward to this.  Please be sure to address the following issues:
>
>   * Debian upgrading guile to a newer version, without recompiling
>     guile-foo which depends on a hygienically introduced identifier.
>
>   * A user modifying a Scheme file from Guile, in the spirit of the
>     LGPL, and expecting it to work with program Foo, without recompiling
>     Foo (again, in the spirit of the LGPL).

If we must avoid the recompilations, then I see only one solution:
simply refrain from introducing hygienic top-level identifiers in the
expansions of public interfaces.  IMHO, this isn't so bad.  If a
top-level variable needs to be expanded in user code, then you'd better
explicitly choose a stable name for it.  If you want the name to be
programmatically based on some or all of the macro arguments, this can
already be done using `symbol-append', `datum->syntax' et al.  The point
is, it's better for the user to do this explicitly.  In the general
case, where a macro may have been considerably reworked from one version
to the next, it's _impossible_, even in principle, for the system to
reliably decide the correspondence between top-level gensyms in the new
code vs the old code.  Even your method is only a heuristic that will
often do the wrong thing, in both directions: it will cause unintended
name collisions in R5RS standard code, and it will also sometimes change
the name of a top-level when you didn't want it to.

* * * * *

There's another option: we could properly track the compile-time
dependencies of each module, and automatically consider a .go file stale
if _any_ of its compile-time dependencies are newer than it.

To be more specific: I think we need to record, in every syntax
transformer bound at top-level, the name of the module where it's bound.
Then, within the dynamic extent of `compile-file', (probably using a
fluid) we'd need to accumulate the set of modules whose macro
transformers are used during compilation of the file.  This set of
modules (the compile-time dependencies) would be included in the .go
file.

I think we need this _anyway_.  Right now, if you change the way an
exported macro works (for example a macro that defines a record type),
you must _manually_ force recompilation of other modules that expand
that macro.  I actually ran into this problem while working on adding
new compiler environment types.

* * *

Furthermore, we could provide distros with the necessary infrastructure
to automatically recompile guile modules as needed after package
upgrades.

I know of at least one precedent for this behavior: the emacs packages
in Debian.  Last I checked, Debian had an elaborate system for
automatically recompiling all third-party emacs packages after a new
version/fork of emacs is installed.  Furthermore, when you install a
third-party emacs package, it is compiled separately for each
version/fork of emacs that is currently installed.

The idea is that .elc files are needed for every ordered pair (e,p)
where `e' is a version/fork of emacs, and where `p' is an .el source
file.  Therefore, neither the emacs packages nor the third-party
packages are able to do the right thing on their own.  The emacs-common
handled all of this magic.

Something similar should be done for Guile, and if we provide the right
tools, we could make it relatively easy for distros to do this.

What do you think?

      Mark

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

[David Kastrup]

Mark H Weaver <mhw@netris.org> writes:

> Furthermore, we could provide distros with the necessary
> infrastructure to automatically recompile guile modules as needed
> after package upgrades.
>
> I know of at least one precedent for this behavior: the emacs packages
> in Debian.  Last I checked, Debian had an elaborate system for
> automatically recompiling all third-party emacs packages after a new
> version/fork of emacs is installed.  Furthermore, when you install a
> third-party emacs package, it is compiled separately for each
> version/fork of emacs that is currently installed.
>
> The idea is that .elc files are needed for every ordered pair (e,p)
> where `e' is a version/fork of emacs, and where `p' is an .el source
> file.  Therefore, neither the emacs packages nor the third-party
> packages are able to do the right thing on their own.  The
> emacs-common handled all of this magic.
>
> Something similar should be done for Guile, and if we provide the
> right tools, we could make it relatively easy for distros to do this.
>
> What do you think?

You should look for other role models.  The Debian Emacs package system
is not understood by any upstream Emacs or XEmacs developer I know: if
they work on a development version of Emacs or XEmacs, they compile all
the packages they use themselves instead of using the packages
preinstalled in Debian.  Because it is pretty much impossible to
understand how to use the Debian system in a finite amount of time.  And
I doubt it is properly understood by its creators.

It places the .el files in common directories for all architectures,
flavors and versions, and it places the compiled .elc files in separate
directories, one for each.  As a result, .el and .elc files reside in
different directories.  Recompilation with the normal Emacs commands is
not feasible.  The load-path contains the .el files in a late position,
the .elc files earlier.  If you do custom development of a package that
is installed system-wide, you may get a nice mixture of versions since
this setup is not capable of sensibly dealing with load-path shadowing
(files in several places in the load-path).  It is no use calling
M-x list-load-path-shadows RET since you get gazillions of diagnostics
just for the normal Debian setup.

If you create something like that, expect _nobody_ to be able to work
with or on it casually.

-- 
David Kastrup

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

[Mark H Weaver]

David Kastrup <dak@gnu.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Furthermore, we could provide distros with the necessary
>> infrastructure to automatically recompile guile modules as needed
>> after package upgrades.
>>
>> I know of at least one precedent for this behavior: the emacs packages
>> in Debian.  Last I checked, Debian had an elaborate system for
>> automatically recompiling all third-party emacs packages after a new
>> version/fork of emacs is installed.  Furthermore, when you install a
>> third-party emacs package, it is compiled separately for each
>> version/fork of emacs that is currently installed.
>>
>> The idea is that .elc files are needed for every ordered pair (e,p)
>> where `e' is a version/fork of emacs, and where `p' is an .el source
>> file.  Therefore, neither the emacs packages nor the third-party
>> packages are able to do the right thing on their own.  The
>> emacs-common handled all of this magic.
>>
>> Something similar should be done for Guile, and if we provide the
>> right tools, we could make it relatively easy for distros to do this.
>>
>> What do you think?
>
> You should look for other role models.  The Debian Emacs package system
> is not understood by any upstream Emacs or XEmacs developer I know [...]

I didn't propose Debian's emacs package as a "role model", but merely as
a precedent, that it is not unheard of for the installation of one
package to trigger automatic recompilation of other packages.

> It places the .el files in common directories for all architectures,
> flavors and versions, and it places the compiled .elc files in separate
> directories, one for each.  As a result, .el and .elc files reside in
> different directories.

This would not be an issue here.  Whereas the Debian packages support
multiple incompatible variants of emacs (e.g. Xemacs), we don't need to.

     Mark

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

[dsmich]

---- Mark H Weaver <mhw@netris.org> wrote: 
> There's another option: we could properly track the compile-time
> dependencies of each module, and automatically consider a .go file stale
> if _any_ of its compile-time dependencies are newer than it.
> 
> To be more specific: I think we need to record, in every syntax
> transformer bound at top-level, the name of the module where it's bound.
> Then, within the dynamic extent of `compile-file', (probably using a
> fluid) we'd need to accumulate the set of modules whose macro
> transformers are used during compilation of the file.  This set of
> modules (the compile-time dependencies) would be included in the .go
> file.

I think we should have this.

-Dale

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

[Ludovic Courtès]

Hello!

Mark H Weaver <mhw@netris.org> skribis:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Wed 16 Nov 2011 04:58, Mark H Weaver <mhw@netris.org> writes:
>>
>>> I think there are better ways to address this problem.  I will explore
>>> these in another email.
>>
>> I look forward to this.  Please be sure to address the following issues:
>>
>>   * Debian upgrading guile to a newer version, without recompiling
>>     guile-foo which depends on a hygienically introduced identifier.
>>
>>   * A user modifying a Scheme file from Guile, in the spirit of the
>>     LGPL, and expecting it to work with program Foo, without recompiling
>>     Foo (again, in the spirit of the LGPL).
>
> If we must avoid the recompilations, then I see only one solution:
> simply refrain from introducing hygienic top-level identifiers in the
> expansions of public interfaces.  IMHO, this isn't so bad.  If a
> top-level variable needs to be expanded in user code, then you'd better
> explicitly choose a stable name for it.

That’s right.  However, in some cases, one may want to write a macro,
that introduces an identifier that’s really an implementation detail,
and something the author does not want users to bother with.

See, for instance, ‘define-wrapped-pointer-type’.  Initially, I would
have liked to not have a TYPE-NAME argument, because it’s not necessary
for the user, and really an implementation detail.  Yet, producing a
hygienic top-level name wasn’t possible, so the TYPE-NAME argument had
to be kept.

This is acceptable in this example, but one could probably come up with
use cases where it’s more embarrassing.

> If you want the name to be programmatically based on some or all of
> the macro arguments, this can already be done using `symbol-append',
> `datum->syntax' et al.

Yes, but it’s not hygienic.

[...]

> To be more specific: I think we need to record, in every syntax
> transformer bound at top-level, the name of the module where it's bound.
> Then, within the dynamic extent of `compile-file', (probably using a
> fluid) we'd need to accumulate the set of modules whose macro
> transformers are used during compilation of the file.  This set of
> modules (the compile-time dependencies) would be included in the .go
> file.

Sounds like a good plan!

> I think we need this _anyway_.  Right now, if you change the way an
> exported macro works (for example a macro that defines a record type),
> you must _manually_ force recompilation of other modules that expand
> that macro.  I actually ran into this problem while working on adding
> new compiler environment types.

Yes, that’s something one quickly encounters when incrementally
modifying code with Geiser, for instance.

Thanks,
Ludo’.

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

[Andy Wingo]

Hi Mark,

On Sat 14 Jan 2012 21:37, Mark H Weaver <mhw@netris.org> writes:

> If a top-level variable needs to be expanded in user code, then you'd
> better explicitly choose a stable name for it.

Indeed, this is the best solution, for interface stability.

But what should happen when users do introduce top-level variables in
their macros, against our recommendations?  My point is that the answer
cannot be, "generate a truly random identifier".  Simply advising users
not to introduce bindings is not a great answer.

> In the general case, where a macro may have been considerably reworked
> from one version to the next, it's _impossible_, even in principle,
> for the system to reliably decide the correspondence between top-level
> gensyms in the new code vs the old code.  Even your method is only a
> heuristic that will often do the wrong thing, in both directions: it
> will cause unintended name collisions in R5RS standard code, and it
> will also sometimes change the name of a top-level when you didn't
> want it to.

Of course.  It's a heuristic.  We document the heuristic and move on,
no?  If users really find themselves caring about this, they will have
to learn the heuristic.

> There's another option: we could properly track the compile-time
> dependencies of each module, and automatically consider a .go file stale
> if _any_ of its compile-time dependencies are newer than it.

We do need to do this, yes.  This would be a great thing to add, once we
switch to ELF as our format of compiled files.  (You would add a section
for this.)

> Furthermore, we could provide distros with the necessary infrastructure
> to automatically recompile guile modules as needed after package
> upgrades.

That is orthogonal to this question.  Recompilation can be triggered on
package dependencies, instead of embedded expansion dependencies.
That's what I was planning on doing for the guildhall, for example.

Regards,

Andy
-- 
http://wingolog.org/