Re: hygiene and macro-introduced toplevel bindings

[Andy Wingo]

On Mon 28 Feb 2011 01:15, Andreas Rottmann <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>
>>   (define-accessor get-x set-x! 0)
>>
> This example serves to illustrate the issue, but I want to make clear
> that there are situations where one cannot work around "cleanly" around
> this issue

Sure, a better example would be:

  (define-syntax define-syntactic-accessor
    (syntax-rules ()
      ((_ getter setter init)
       (begin
         (define val init)
         (define-syntax getter
           (syntax-rules ()
             ((_) val)))
         (define-syntax setter
           (syntax-rules ()
             ((_ x) (set! val x))))))))

>> The issue is, what happens when this expression is expanded?

Specifically, in Guile right now:

  (define-syntactic-accessor foo set-foo! #f)

expands to:

  (define val #f)
  (define foo (make-syntax-transformer 'foo (lambda ...)))
  (define set-foo! (make-syntax-transformer 'foo (lambda ...)))

If we generated a name for val, it would be

  (define val-234123 #f)
  ...

where the syntax transformer lambdas reference that "unique" name.
(Ensuring uniqueness is another issue.)

>> Anyway, in Guile our modules have always been first-class entities.  We
>> never intern gensym'd names in modules, because who would do that?  You
>> put a name in a module because you want to be able to name it, either
>> internally or externally, and gensym'd names don't make any sense
>> without some sort of translation table, and Guile's first-class modules
>> have no such table.
>>
> Sorry, I don't understand the part about the translation table, could
> you clarify?

For the same reason that we want to see real variable names in
backtraces, and not de bruijn numbers, we would want to know what name
"val-234123" corresponds to -- when traversing modules, in tab
completion, etc.  We would need a translation table for that purpose.

> I agree that it makes no sense to allocate a named binding in the module
> for `val'

But you have to, I think.  If that module that contained the above
define-syntactic-accessor expansion exports "foo", then in another
module you have:

  (define bar (lambda () (foo)))

which expands to

  (define bar (lambda () val-234123))

Val needs to be named.

> consider this:
>
> (define-accessor (get-foo set-foo! #f))
> (define-accessor (get-bar set-bar! #f))

Yep, bad.

> Ideally, Guile would allocate an "anonymous binding" inside the module
> -- a binding that has only a location, and lacking a visible name.

Would that this were possible, but I hope the discussion above is
sufficient to convince you that, under the covers at least, "val" needs
a name.  Separate compilation units refer to parts of each other by
name.

And then what happens if you recompile the module that defined the
syntactic accessors?  Your other, separately compiled module probably
breaks.  Then again this can happen more generally with macros.

Guile could indeed introduce gensym'd names.  It would be a bit nasty
but it would work.  But is it the right thing?  Top-level names are
interface, even if they are not (directly) exported from your module.  I
would be happier if we instead took care in choosing those names,
instead of hiding them under the syntactic covers.

Regards,

Andy
-- 
http://wingolog.org/