>What you are saying means it is not homoiconic any longer. If you print out the parsed representation of lisp code, you get back the same lisp code. If you print out the parsed representation of this whitespace code, you get back the lisp code (data) also. But this is different to what you fed into the parser.
I don't know if we're talking past each other here.
lisps internal representation of (foo (bar (baz 1))) is not literally just that.
it is a linked list, generally (?).
An indented version of the above:
foo
bar
baz 1
is exactly the same, as is the tcl version:
foo{ bar{ baz{ 1 }}}
The structure describes the data.
you can turn that internal representation back to a lisp list, or you could turn it into json or tcl or whatever.
Homoiconicity also means, as I understand it, that foo would appear the same regardless of whether its built in.
in C for example you have to care whether 'for' is a built in language construct.
you can't do
foo( int i = 1 ; i < x; i++) {}
the language doesn't allow it.
if lisp had:
(for ((= i 1) (< i x) (++ i)) .....)
then that would be homoiconic, and you could make it look like C with a front end, and it would end up as the same internal structure.
It would be more complicated to turn that internal representation into the C like syntax, but it isn't impossible.
I don't know if we're talking past each other here.
lisps internal representation of (foo (bar (baz 1))) is not literally just that.
it is a linked list, generally (?).
An indented version of the above:
foo
is exactly the same, as is the tcl version:foo{ bar{ baz{ 1 }}}
The structure describes the data.
you can turn that internal representation back to a lisp list, or you could turn it into json or tcl or whatever.
Homoiconicity also means, as I understand it, that foo would appear the same regardless of whether its built in.
in C for example you have to care whether 'for' is a built in language construct.
you can't do
foo( int i = 1 ; i < x; i++) {}
the language doesn't allow it.
if lisp had:
(for ((= i 1) (< i x) (++ i)) .....)
then that would be homoiconic, and you could make it look like C with a front end, and it would end up as the same internal structure.
It would be more complicated to turn that internal representation into the C like syntax, but it isn't impossible.