Hi; On Saturday 23 November 2002 12:11 pm, Timothy Moore wrote: > Is your code reinterning symbols found during processing?
Apparently, yes. It looks like it when it reads a "defmacro" form, it explicitly calls eval on the entire form so as to get the macro into the environment. For other things, it definitely interns symbols into the current package. > > However, whenever I find myself running into a situation such as I > > described (effectively unable t > > This is hard for all sorts of reasons. Simple recursive macroexpansion > shouldn't be too bad. Under ANSI rules you shouldn't run into magic This is exactly what I want to do -- very vanilla and boring. > 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?) Thanks again for the help! -jm -- ==== John Morrison ==== MAK Technologies Inc. ==== 185 Alewife Brook Parkway, Cambridge, MA 02138 ==== http://www.mak.com/ ==== vox:617-876-8085 x115 ==== fax:617-876-9208 ==== [EMAIL PROTECTED]
