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

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.

> At the same time, I agree that `make-rename-transformer' isn't right.
> One place this show up is in the package system, where opening a
> package doesn't give you the same bindings in terms of
> `free-identifier=?':
>
>  (define-package p (x y)
>    (define-syntax x
>      (syntax-rules (y)
>        [(x y) 'y]
>        [(x z) 'other]))
>    (define y 'placeholder))
>
>  (let ()
>  (open-package p)
>  (x y)) ; => 'other, instead of 'y
>
> That's because `open-package' introduces new bindings to rename
> transformers, instead of actually splicing the bindings from the
> package.
>
>> Typed Scheme is implemented using a free-identifier-mapping that
>> associates type names with types.  This has the nice property that it
>> cooperates with the module system to track arbitrary requires,
>> provides, and renamings.  Unfortunately, it breaks in the presence of
>> rename transformers.
>
> This sounds like the same problem as for `open-package'. You don't
> specifically need to walk the links. You need a truer renaming --- one
> that works with `free-identifier=?'. Right?

So, in one sense, if (as you suggest) `free-identifier=?' cooperated
with rename transformers, then that would work.  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.

> Ideally, the renaming should work at the level of syntax objects, where
> `free-identifier=?' lives, instead of at the level of transformer
> bindings.
>
> One possibility is a `define-renaming' form that adjusts bindings at
> the syntax-object level. That seems like the right thing at some level,
> but then we'd end up with a zoo of syntactic forms for local binding,
> etc. Also, it would require converting existing code.
>
> Another possibility is to have `free-identifier=?' inspect transformer
> bindings in the current scope, so that it would effectively walk a
> renaming chain in the same way as `syntax-local-value'. That would work
> with existing code, but move `free-identifier=?' out of the pure
> syntax-object level means that it wouldn't work quite always, and it
> might make comparisons significantly more expensive.
>
> 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?

Thanks,
-- 
sam th
samth at ccs.neu.edu