+1 . Last year I was experimenting with require-tranformers and provide-transformers. They are very weird macros, because they have to be executed in the "wrong order" (from inside to outside, like functions). They use a newly created syntax-mark, and to break hygiene you must use syntax-local-require-introduce or syntax-local-provide-introduce (under the hood, the marker is stored in a parameter, but the parameter is not exported, so you can't change/parameterize it).
I think that all of them can be merged in a generalized syntax-local-introduce with a public parameter. The parameter should be used only in a parameterize form. Overwriting the parameter doesn't look like a good idea. I think it will break the current macro and create a syntax error, but it will not be useful to break the security. Gustavo On Mon, Aug 11, 2014 at 4:22 PM, Alexander D. Knauth <alexan...@knauth.org> wrote: > > On Aug 11, 2014, at 1:44 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > >> Answers below, but first a big caution: While these details have been >> the same for a while, I hope and expect the representation of syntax >> objects to change in the coming months. I have been threatening to >> rewrite the macro expander (yes, in Racket) for a while, but things are >> lining up so that I can actually start trying soon. > > > This is off topic, but if your planning on rewriting the macro expander in > Racket, would it be possible to make it so that syntax-local-introduce uses a > parameter? > That way for match expanders (etc.) it could set that parameter to a new > syntax-introducer so that syntax-local-introduce could be used within > match-expanders (etc.)? > > > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users ____________________ Racket Users list: http://lists.racket-lang.org/users
