Hello,
On Mon, Jan 7, 2013 at 8:33 PM, Alex Shinn <[email protected]> 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 > matching. > 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
