At Mon, 9 Mar 2009 20:33:17 -0400, Sam TH wrote: > On Mon, Mar 9, 2009 at 8:22 PM, Matthew Flatt <[email protected]> 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. _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
