3 ms·
Doesn't make much sense. Anyway, the whole concept of 'homoiconic' is underdefined. Plus: the word 'homoiconic' does not really fit well. In Lisp we talk about
by lispm 12y ago
Doesn't make much sense. Anyway, the whole concept of 'homoiconic' is underdefined. Plus: the word 'homoiconic' does not really fit well.
In Lisp we talk about that code is data, other than a string.
Thus we can construct programs by constructing data using the usual primitive data structure functions:
? (list '+ 1 2)
(+ 1 2)
Note that Lisp does not use any special purpose data-structures for code. Nothing like special constructors for AST data structures. One does NOT have to call a MAKE-FUNCTION-CALL procedure. Lisp also does not need to construct programs as strings, where I would have to parse the language with string/stream operations to access individual elements of the program. A number 2 would be represented as text, not as numeric data as in Lisp.
Above is a valid program and it is a list of three elements. There are no strings involved. + is a symbol and 1 and 2 are actually real numbers.
Let's look at the 1:
? (describe (second (list '+ 1 2)))
Fixnum: 1
The interface to executing code is the function EVAL. It takes code as data, and not a string.
? (eval (list '+ 1 2))
3
- agumonkey 12y agoI never mentioned or meant to imply strings anywhere. I'm saying that lisp abstractions: cons, car, cdr, eq*, if, lambda... are enough to write eval in a page. To me the only reason it can be so short is that the abstractions and the interpreter are close to some sort of fix-point, an almost infinite regression in desugaring, and that's what people are thinking about when talking about code as data and homoiconicity.