You may have inadvertently misspoke, but macros operate at compile time, at least in the Lisps I have used.
CLISP example:
[2]> (defmacro add2 (place) (print 'add2) `(incf ,place 2))
ADD2
[3]> (let ((a 1)) (dotimes (i 4) (add2 a)))
ADD2
ADD2
ADD2
ADD2
NIL
[4]>
As one can see the macro form is expanded four times at runtime.Indeed, can you write a program for CLISP that works like this:
- takes one command line argument (a file name)
- reads in the given file, interprets it as Common Lisp code, expecting it to deliver a definition for the add2 macro
- then runs
(let ((a 1)) (dotimes (i 4) (add2 a)))The CLISP REPL does not compile, thus it can't be interleaved.
> then runs
It will still be interpreted and the macro will still be expanded at runtime.
Excepting that it is not really "fraught with danger" unless you are redefining macro's that have already been expanded and cached in function definitions.
Now, Clojure is kind of impaired Lisp because it is written for a VM that was not intended to be used this way and so this is not that much pronounced (but you still get REPL, etc.)
In my naivety I thought functional programs with their emphasis on lack of side effects could help. I then encountered a project that was totally functional but written entirely by people with no functional experience. The entire application was unmaintainable even in the most basic parts.
> Doesn't parse
> Macros
Macros modify code structure at runtime so obviously that is fraught with danger.
> Framework forcing structure
Lisp languages in general have a do it yourself attitude not found in others. While there are frameworks it's common to find projects that have invented from the ground up entire web frameworks, db access and orm.
Imagine if every project you encountered in Java reinvented Rx Java, Hibernate, and Spring.