The need to write macros rather than procedures in Lisps for meta-programming is a conscious one. Once upon a time, in ancient Lisp, it was done in the TCL way. A programmer-defined function called a "fexpr" would be called by the interpreter to handle an unknown form. Having access to its syntax, it could give it any meaning.

Macros work under compilation, and handle interpretation situations too. (Though not all of them; certain trompe d'oeil tricks are possible with fexprs, since they can have access to the contents of the run-time lexical environment, and the syntax, simultaneously, making it possible to interpret the syntax in a way that depends on the run-time value of a variable.)

You're not going to make anything better than Lisp in a programming language by resurrecting hacks that were consciously discarded as a bad design decades ago.

I agree with your specific point, but it's important to remain open to exceptions to the general point.

Re: "Lisp has types, more or less like Python and Ruby

The point is probably that the author regarded it as a disadvantage if a language has types other than the character string.

"Hey look, TCL is better than Lisp for some of the same reasons it is better than Ruby and Python: no damn types."

> You can write a TCL list to a file? You mean a TCL string to a file? Lisp can just write strings to files too.

No, the point is that almost all TCL values are represented as strings which are also valid literals for those values. This is where the similarity with Lisp comes from: Lisp is a language where the syntax is the representation (you write the AST), whereas TCL is a language where the representation is the syntax (you operate on the string).

So all func calls are actually calls to eval?

Again TCL kind of has the opposite perspective: all evaluation is text substitution.

apply actually, which is the eval form for functions. Calls a function with a list of arguments

yes, although there are compilers which statically deconstruct as much as they can

> You can write a TCL list to a file? You mean a TCL string to a file? Lisp can just write strings to files too.

To expand upon this, Lisp can write its lists to files (and most other things out of the box) which it can then read back from files and then eval. This is what Lisps mean by a printable/readable object.

In Clojure:

    (spit "foo.clj" '(defn foo [] "CONGRATS! YOU CALLED FOO!!!"))
    (load-file "foo.clj")
    (foo) ; => "CONGRATS! YOU CALLED FOO!!!"

In Common Lisp:

    (with-open-file (f "foo.lisp" :direction :output)
           (pprint 
             '(defun foo () 
                "CONGRATS! YOU CALLED FOO!!!!") f))
    (with-open-file (f "foo.lisp" :direction :input)
           (eval (read f)))
    (foo) ; => "CONGRATS! YOU CALLED FOO!!!!"

Serializing code like this is a bad example, because you need to introduce eval into the loop, which is another step entirely from printing and reading objects. Consider this example, from REPL interaction:

  CL-USER> (with-open-file (f "/tmp/makapaka"
                            :direction :output
                            :if-exists :supersede)
             (pprint '(a potentially (complex data structure)
                       mixing lists #(and vectors) 2/3
                       #C(2 5) and stuffs) f))
  ; No value

  CL-USER> (with-open-file (f "/tmp/makapaka")
             (read f))
  (A POTENTIALLY (COMPLEX DATA STRUCTURE) MIXING LISTS #(AND VECTORS) 2/3 #C(2 5)
   AND STUFFS)

In this example, I printed and read back a list containing symbols, lists, vectors, rationals and complex numbers.

Basically: the reader converts strings to Lisp objects[0]. The printer converts Lisp objects into strings. When we say that an object has a "readable representation", it means that if you feed the result of the printer into reader, you get the same object back.

The evaluator (which I didn't use here, but OP did) evaluates Lisp objects (not strings!), and can e.g. introduce a new function to the environment when evaluating a defun form, i.e. a list of form (defun name (args...) "docstring" code). It is not needed (in fact, it is discouraged[1]) when all you care about is writing and reading back Lisp objects.

--

[0] - Note it's the same reader that actually reads your code when you compile/load file or use a REPL.

[1] - The usual eval-on-untrusted-data code execution vulnerability. Note that since the reader is mostly used to process code, by default it allows you to use the #. read-time-value reader macro. If you READ a string like: "(1 2 #.(* 2 2))", you'll get a Lisp list (1 2 4), since #. basically means "pipe the next s-expression to eval, and return that". When you use reader/printer for serialization/deserialization, you usually want to disable #. for those invocation of read function, by setting

  *READ-EVAL*

variable to NIL.

> You can write a TCL list to a file? You mean a TCL string to a file?

No - and I think this is entirely what the comment about Lisp was about.

In tcl, there is no distinction.