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

[Mark H Weaver]

Hi Andy,

Andy Wingo <address@hidden> writes:
> On Thu 10 Nov 2011 05:36, Mark H Weaver <address@hidden> 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 <address@hidden>
> Subject: Re: Are generated toplevel definitions secret?
> Newsgroups: gmane.lisp.scheme.reports
> To: "Aaron W. Hsu" <address@hidden>
> Cc: scheme-reports <address@hidden>
> 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 <address@hidden> 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