On Mon, May 2, 2016 at 10:44 AM, Alex Knauth <alexan...@knauth.org> wrote: > >> On May 2, 2016, at 10:00 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> >> wrote: >> >> The problem with your first example is that there are some extra >> scopes on `#'x` from the context that it's in. If you use >> `(datum->syntax #f 'x)` (producing a syntax object with no scopes on >> it) then your tests pass. > > Trying to understand this. Ok, so, there are scopes in the context of the > transformer function, which are preventing this example from working. So, why > doesn't syntax-local-introduce remove those scopes? If it's supposed to say > "pretend that this syntax was part of the input," and an input syntax object > wouldn't have those scopes, should it remove them? Or would that cause other > problems? > > The functions produced by `(make-syntax-introducer)` take an extra argument, > which can be 'flip, 'add, or 'remove. Right now the default for > `(make-syntax-introducer)` functions is 'flip.
My initial statement was less precise than my second email. `(syntax-local-introduce stx)` adds a single scope, using the equivalent of `'flip` mode. That scope is "the current scope" for the macro expansion step. We could add an optional argument to `syntax-local-introduce` to control the mode -- the current implementation of `local_introduce` in env.c calls scheme_stx_flip_scope, but changing that to use a mode would be relatively simple, as C code goes. I'm not sure how useful it would be, though. Sam >> What `syntax-local-introduce` does is add precisely the scope that the >> expander added to indicate the input to the macro that you're >> defining. > > If it adds that scope, but doesn't take away the other scopes that were > messing up this example, does that mean `syntax-local-introduce` is in 'add > mode, in terms of the modes of `(make-syntax-introducer)` functions? Would it > mean anything to make `syntax-local-introduce` take an optional extra > argument like this? > > Would this example work if this use of `syntax-local-introduce` was in 'flip > mode? > > Alex Knauth > >> On Mon, May 2, 2016 at 9:53 AM, Matthew Butterick <m...@mbtype.com> wrote: > >>> Sorry to be dense, but I still don't see the "pretend that this identifier >>> was in the input" angle. Below, example 1 fails with an unbound-identifier >>> error, because the `syntax-local-introduce` identifier does not capture the >>> use-site reference. Whereas example 2 works, even though the `invoke-x` >>> macro ostensibly uses a hygienic reference. >>> >>> Having looked at the scope sets, I now understand WHY the behavior below >>> happens. But `syntax-local-introduce` clearly does something quite >>> different from, say, `(datum->syntax caller-stx datum)` (whose behavior I >>> think of as "pretend that this identifier was in the input"). > >>> #lang racket >>> (require rackunit) >>> >>> (module macros racket >>> (provide (all-defined-out)) >>> (define-syntax (sli-x stx) >>> (syntax-case stx () >>> [(_) (with-syntax ([x (syntax-local-introduce #'x)]) >>> #'(define x 'syntax-local-introduce-x))])) >>> >>> (define-syntax-rule (invoke-x) x)) >>> >>> (require 'macros) >>> >>> ;; example 1 >>> (check-equal? >>> (let () >>> (sli-x) >>> x) 'syntax-local-introduce-x) >>> >>> ;; example 2 >>> (check-equal? >>> (let () >>> (sli-x) >>> (invoke-x)) 'syntax-local-introduce-x) >>> > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
