[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] auxiliary syntax


On Mon, Jan 7, 2013 at 8:33 PM, Alex Shinn <alexshinn@x> wrote:
(If so, it sounds like syntax parameters may be the solution. But at this point I'm just trying to make sure I understand the problem.)

Yes, I believe syntax-parameters could be used.  It would be clumsy, since the
macros involved would have to syntax-parameterize the entire SRE language on
each expansion.  But if we're entertaining non-standard extensions then it's much
simpler, easier to port and more robust to just use an ER macro with unhygienic

Thinking about it more, I don't quite see how syntax-parameters could do this. I believe your goal is that certain symbols (*, ?, and =>, and maybe more) would have meanings in the context of SREs that are different than their meanings in other parts of a program. (Some people might say that you shouldn't have this goal, but I think it should be possible.)

In that case, what binding could the symbols have to make that work? Either they're bound to things that your macros know about, in which case => breaks inside cond expressions (and * might break as a function), or they're not bound to things from your macro package, in which case your package won't match them.

It really seems like your goal is explicitly unhygienic - the same symbol has a different meaning inside certain macros, even though the user didn't every bind it differently. I still think that should be possible, but I don't see how syntax-parameters is going to accomplish it (although I would love to hear why it will). syntax-parameters could rename all of your auxiliary syntax, though, which would also be nice to allow.

Sadly, I don't know a solution to this off-hand. :-)

Noah Lavine

Scheme-reports mailing list