> On Oct 8, 2015, at 9:00 AM, Lyle Kopnicky <lylew...@gmail.com> wrote: > > Yes, sorry, I've been traveling and didn't have time to respond. I was > originally tempted to say "statically typed" and then realized that wasn't > exactly right, because it was not static types that would forbid such a > construction, so I said "static languages" suggesting languages where things > cannot be so easily changed.
Ok I think I see what you're saying. Unhygienic macros capture bindings from the use site, which breaks lexical scope and brings it closer to looking like dynamic scope, and unhygienic reader extensions do the same thing. But that's why we have hygienic macros and hygienic reader extensions; to restore lexical scope, which is static. > I'm not so familiar with reader macros. The documentation looks pretty > extensive so I don't have to time to absorb it right now. Reader extensions are not my favorite part of racket. Whenever I make them, they feel like a bit of a mess. > I would imagine that macros are not closures, therefore they shouldn't have > any free variables. Half the point of hygienic macros is that they can "close over" variables that would otherwise appear to be free variables, but are actually bound to some variable in the context of the macro definition instead of the context of the macro use site. So they can act like closures. And it's in that analogy of hygienic macros as closures that unhygienic macros look like dynamic scope. But hygienic macros can "close over" these things to restore lexical scope. Hygienic reader extensions can do the same thing, although there can be some complications with an identifier being bound to an identifier that is not available anywhere that the use site module knows about. So for instance the afl meta-language expands to lambda from racket/base, but it only works when the base language depends in some way on racket/base. That base language doesn't need to provide the lambda from racket/base, but a dependency has to be there somewhere. That isn't a lot to ask, but it does means that for instance #lang afl racket/kernel won't work. Matthew Flatt explained to me that for normal macros, this is handled automatically, but not for reader extensions. > Matthew Flatt gave a nice demonstration of a clean way to do that (using > multiple scopes with colors). I'm not sure how things might be different for > reader macros, though. It seems to me that while the input of a reader macro > is different (plain text instead of sexprs), the output is still sexprs, so > the same sort of scoping rules should apply. For hygienic macros to avoid this capturing behavior, there has to be a color at the use site of the macro that is not in the context of the definition of the macro. This is handled automatically by default. For hygienic reader extensions, the same principle applies, but you have to do that yourself because it's not handled automatically. Also, there has to be a dependency somewhere on the module that provides the identifier, which is another thing macros handle automatically and reader extensions don't. -- 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.
