>>21
You can't access run-time bindings in CL either. A macro function (either directly written and set or bound in the
macro-function namespace or as generated by
defmacro, which does the same) just takes in a list (represented as if one were to quote the code, or more precisely, the output given by the reader, which may include some objects generated at read-time) and an environment (generated by the compiler, contents is implementation-defined). The macro function is supposed to return the processed function body with the macro expanded, which is then passed to the compiler to further expand or compile. Nowhere here says anything about being able to change run-time bindings, as that obviously only exists at the run-time. The environment may contain lexically accessible bindings, but I don't think you can portably access them, you can however, check if local/lexical macros are bound within the scope of the macro being expanded as well as a few other things. However, if you don't mind writing slightly unportable code, I did write some de-facto portable (working across most major CL implementations I had my hands of, such as SBCL, ClozureCL, CLISP, ECL, some of the commercial ones, ...) macros which access all kinds of environment information, including lexically-bound variables. If you actually want to change values of the variables at runtime, that's not something a macro can or should be able to do (except maybe expand code that does it), and in that case CL is not for you, you should be using some ancient interpreted LISP which supports FEXPRs(not Common Lisp or Scheme, although technically it's not hard to implement them in CL at the cost of making slow-as-mollasses code for anything which doesn't have a fast interpreter), or some resurrected version of these ancient LISPs such as newLISP.