Re: `set!' of generated temporary in macro expansion causes warning

[Mark H Weaver <mhw@netris.org>]

Hi Andy,

Andy Wingo <wingo@pobox.com> writes:
> p.s.  Regarding hygienically introducing identifiers, I had an idea.
> From a mail I sent to scheme-reports:
>
>     To recap:
>
>        (define-syntax define-const
>          (syntax-rules ()
>            ((_ name val)
>             (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 predicatable.
>
>     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.)

This won't work.  Two identical invocations of the same macro must
generate distinct toplevel variables, in the same way that identical
invocations of the same procedure must generate distinct lexical
variables.  Therefore, the name must depend not only on the form;
identical forms must somehow be made unique.  One possibility is to
include the source code location in addition to (or instead of) the
form.

Furthermore, it is not sufficient to include only one incoming form.  We
must include the entire stack of incoming forms (each annotated to make
them unique).  Suppose macro A invokes macro B twice, and macro B makes
a private top-level variable.  Invoking macro A once should create two
distinct top-level variables.

If these names were constructed from the stack of source code locations,
this could also be a great help in generating useful error messages
involving these generated top-level variables.

    Best,
     Mark


>     That way you do preserve the "compatible recompilation" aspect, trading
>     off true secrecy, but hey.  Oh well.
>
> This would obviously be for master / 2.2 and not 2.0.