> It's pretty trivial to add macros to any language. Not true. > The only thing that separates a macro from a regular function is time. In a normal function,

> It's pretty trivial to add macros to any language. Not true. > The only thing that separates a macro from a regular function is time. In a normal function, the parameters are evaluated before being sent to the function. In a macro, the function is called before the parameters are evaluated. That's not really capturing it. A regular function expects to get passed evaluated results from valid code. The arguments are being evaluated. The function gets called and the parameters will be bound to these arguments. A Lisp macro OTOH gets arbitrary stuff passed. A Lisp macro can enclose anything. This anything can look totally wild and does not need to be valid code. The macro gets this anything, it has to compute valid source code and can create any side effect it wants. In a macro form, the macro function gets called with the code it encloses and an environment. It can then do anything it wants, but it has to return valid code. This code then will be evaluated - the generated code can be anything which is in that context a valid Lisp form: self-evaluating data, a variable, a special form using built-in Lisp syntax, a function form or another macro form. > (If you're not familiar with lisp. a form is kind of like a line of code, it's usually a function call but it can be a value as well) A 'form' is an expression which is also a valid Lisp expression (can be evaluated, etc.). > But it's not Lisp's individual features that make it what it is, it's how these features interact with one another to give you something that's truly hard to replicate. Yep, that's a good insight.