On 06/17/2017 08:02 PM, Matthew Flatt wrote: > As a `require` form, a `submod`'s binding context is taken from the > parenthesis around the `submod`. With options (A) and (B), the context > of those parentheses is macro-introduced.
Thanks! So this `submod` binding context is being used to mark the ultimately-introduced identifiers, right? So, in the example, v1 would be marked with the (macro-introduced) context of the `submod` form. And it is this marking that prevents the use of v1 in `main` from lining up with the definition of v1. This seems weird to me for two reasons. First, it seems like since the whole point of require is to pollute the surrounding namespace, an "unhygienic" require would be better. (I don't know how this would work!) And second, I'm used to macros hinging on the binding of the identifier in their car, namely `submod` here. (Using #'submod instead of 'submod in option (C) works fine too, incidentally.) This point is definitely minor compared to the first one. Either way, I was confused that the obvious thing didn't work, and maybe other authors of define-require-syntax transformers start out confused too. It took me quite a while, and past scars from mysterious binding problems, to think of option (C). My past experiences of this kind of problem have all been related to #lang and module and require-level binding, come to think of it. It seems a murky area. Perhaps other kinds of hygiene-preserving techniques than those that work well for expressions are needed for these areas? Cheers, Tony PS. Why do *parentheses* have a binding context, anyway?? -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
