I was playing with code generation outside macro being inspired by corrected version of nif
https://letoverlambda.com/index.cl/guest/chap3.html#sec_5
When I replace the usual gensym with my interned-gensym I can skip the eval and have more noob friendly version of the code that I can easily copy to REPL for further experiments with macro code creation.
When it’s done, will I be able to replace with defmacro?
Why the usual gensym in macro is not interned?
Besides the eval is evil, what are other pitfalls of writing code this way?
(defun interned-gensym ()
"More suitable variant of gensym for macro experiments"
;; file:~/Programming/sbcl/src/code/symbol.lisp::593
(values (intern (format nil "Z~A"
(let ((old *gensym-counter*))
(setq *gensym-counter* (1+ old))
old)))))
;;; nif
(eval (apply (lambda (expr pos zero neg)
(let ((gexpr (interned-gensym)))
`(let ((,gexpr ,expr))
(cond
((plusp ,gexpr) ,pos)
((zerop ,gexpr) ,zero)
(T ,neg)))))
;; args for the lambda
((- 5 2) :positive :zero :negative)))
You might want to check the indentation of your code. It looks not right. Do you use TAB characters in your editor? Don’t!
One problem could be, that your code is not working, because you have a bug in your EVAL form. Did you actually try to run it?
Because then there is no name clash with symbols written by the macro user. If you would intern gensyms, where would you intern it? In which package Your variant does not say, whatever the current package is the symbol will be interned. If the user has a symbol there, one may get random (hard to debug) name clashes.
EVAL is not ‘evil’. It’s just most of the time not needed and you need to understand what it does. EVAL evaluates the code always in the global environment. EVAL also may not compile the code, so it may run interpreted, depending on the Common Lisp implementation.