unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel@gnu.org
Subject: Re: GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a
Date: Thu, 10 Nov 2011 11:46:06 -0500	[thread overview]
Message-ID: <87y5vox6wh.fsf@netris.org> (raw)
In-Reply-To: <871utgcr4g.fsf@pobox.com> (Andy Wingo's message of "Thu, 10 Nov 2011 09:34:55 +0100")

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



  reply	other threads:[~2011-11-10 16:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1RNMul-0000TQ-6L@vcs.savannah.gnu.org>
2011-11-10  4:36 ` GNU Guile branch, master, updated. v2.1.0-102-g0f9f51a Mark H Weaver
2011-11-10  8:34   ` Andy Wingo
2011-11-10 16:46     ` Mark H Weaver [this message]
2011-11-11 20:20       ` Ludovic Courtès
2011-11-15 20:58         ` Andy Wingo
2011-11-15 21:12       ` Andy Wingo
2011-11-16  3:58         ` Mark H Weaver
2012-01-06 17:47           ` Andy Wingo
2012-01-14 20:37             ` Mark H Weaver
2012-01-14 20:54               ` David Kastrup
2012-01-14 21:39                 ` Mark H Weaver
2012-01-14 22:01               ` dsmich
2012-01-14 23:40               ` Ludovic Courtès
2012-01-15 11:44               ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y5vox6wh.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).