[plt-dev] syntax-local-value and identifier-mappings

At Mon, 9 Mar 2009 20:33:17 -0400, Sam TH wrote:
> On Mon, Mar 9, 2009 at 8:22 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > At Mon, 9 Mar 2009 16:15:46 -0400, Sam TH wrote:
> >> Right now, `syntax-local-value' cooperates with
> >> `make-rename-transformer' to 'do the right thing'.  However, it's not
> >> possible to build any other abstractions with the same property, since
> >> you can't get out the target of a rename transformer (you can't even
> >> tell that an identifier is bound to one).  It would be nice if
> >> `syntax-local-value' took an additional argument to specify that it
> >> shouldn't loop, so that other abstractions could be built that
> >> respected rename-transformers.
> >
> > I've tried this before, following much the same rationale. It turned
> > out not to solve the problems that motivated it before, though, and so
> > I removed that capability in an attempt to keep renaming more abstract.
> > In particular, making intermediate names accessible might provide
> > access to a scope that is otherwise unavailable (by taking a
> > intermediate identifier's context and transferring it to a different
> > symbol).
> 
> It seems like this sort of 'attack' is something the certificate
> system should be preventing.

Yes, I suppose it would. Maybe that's not a problem after all.

Still, getting `free-identifier=?' to work seems like a more useful
result.

> But the other
> constraint is that I need the binding form to operate at the
> expression level, since the code that uses `make-rename-transformer'
> looks like this:
> 
> (define-syntax foo
>    (if (typed-context?)
>        (make-rename-transformer #'foo*)
>        (make-rename-transformer #'other-foo)))
> 
> so something like `define-renaming' wouldn't work.

It depends on what's allowed on the right-hand side of
`define-renaming'. In any case, triggering `define-renaming'-like
behavior through a rename-transformer result would allow the above
pattern.

> > One last possibility, which I had not really considered until now, is
> > to have the macro expander treat a transformer binding to a renamer by
> > applying a syntax-object renaming immediately, instead of merely
> > installing a transformer binding. That sounds promising to me, and I
> > could give it a try next week or so.
> 
> I'm not sure what you mean here.  Would this be the expander that
> processes the binding, or the reference?

The expander. The expander already applies one kind of syntax-object
renaming for the binding introduced by `define', `define-syntax',
`let-values', `letrec-syntax', etc. When it sees a rename-transformer
value for a transformer binding, it would apply an additional
syntax-object annotation, which `free-identifier=?' would use to
connect the old and new bindings.