On Sun, 24 Nov 2002, John Morrison wrote: > Hi; > > On Saturday 23 November 2002 12:11 pm, Timothy Moore wrote: > > > special forms that you can't deal with, though you may encounter magic > > functions. One of the harder things to deal with is backquote; an > > This is (I think) where I'm running into trouble. > > > implementation has a lot of latitude to return anything it wants as > > long as it gives the proper results at run time. Even Common Lisp > > compilers like SBCL load their own backquote implementations into the > > host Lisp so they know what's going on. As your language departs from > > CL it gets even harder. > > OK. Does this mean: > > (0) There is a portable way to do this, and I have failed to use it, > or > > (1) This is just plain hard, there is no portable way to do it, so I > should just quit complaining and suck it up and press on with > implementation-dependent approaches (assuming they always exist), or > > (2) This is not the right way to give users this macro capability > (e.g., I should enable my users to extend my input language's grammar > not in the input language, but instead force them to segregrate the > extension macros in a separate, vanilla CL file which is basically a > compiler extension, or something like that?)
The only sane way to think about backquote is to realize that it's a macro that only makes sense in the body of executable code. In other words, it's not a read macro, despite its heavy use of read time syntax. You can't use backquote all over the place even in Common Lisp e.g., defining forms like defclass. If you want to support backquote in your language without reimplementing it, I suggest that you turn your defning forms that use it into functions that return your language's forms and then process the results of that. Tim
