Re: hygiene and macro-introduced toplevel bindings

[Noah Lavine]

Hello all,

I believe what I'm saying is equivalent to what Andreas said, but let
me put it in this way: I think the Right Thing to do is to change what
we think of as a name - instead of a name being a symbol, a name would
be a symbol plus the environment it was defined in (which is what a
syntax object is, right?). That would solve this issue, because each
expansion of the macro would get a different environment (this must
happen because this is already how hygiene works, right?).

Then ideally we would modify the backtrace code to print these things
nicely, so it would say something like:

val (defined in call to define-syntactic-accessor, file.scm:53) = 5
val (defined in call to define-syntactic-accessor, file.scm:55) = 7

And then you'd probably special-case it so that each module had a
"top-level environment" which didn't print with parentheses, which
would hold things that were not defined in any macro, so you could
also have

val = 9

for the result of running (define val 9) at the module's top level.

Does this sound right to people?
Noah

On Mon, Feb 28, 2011 at 4:28 PM, Andy Wingo <address@hidden> wrote:
> 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/
>
>