If one uses a Lisp interpreter, macro expansion may happen at runtime.

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.

This is a confusing example, because in a REPL steps of compilation and evaluation are interleaved.

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)))

> This is a confusing example, because in a REPL steps of compilation and evaluation are interleaved.

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.

I don't know Lisp well, but I remember PG saying in one of his books or essays, that Lisp is a language in which you can compile and run at read time, and the other two possibilities, too.

Macro's are evaluated inside of 'defun, however, 'defun is evaluated during runtime (when the .lisp file is being loaded into the implementation) so base698 is technically correct.

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.

In full Lisp "compile time" is part of application execution.

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.)

Is there anything lacking from the JVM beyond tail-call elimination that Lisp needs? I know Clojure is very slow to start up but my understanding is that this is because it uses the JVM very inefficiently, and they don't seem to care much.