3 ms·

What the author did is cool in a social sense; lispers go on and on about homoiconicity, which here means that the original lisp code is data. The author uses t

What the author did is cool in a social sense; lispers go on and on about homoiconicity, which here means that the original lisp code is data. The author uses this property by reading this code/data and transforming it into text, that represents syntax-full code. It is "cool" because it demonstrates the value of homoiconicity. However; it's not cool in a technical sense. The result is not homoiconic any more. Code that had a cool property has been turned into code that does not, and the result looks like every other syntax-full blub language. The result destroys value.

benj111 2y ago
(foo (bar (baz 1))) is equivalent to foo bar baz 1 Its still homoiconic they can still, and in the case of the linked project, probably are turned into the exact same data structure. I get your objection insofar as whats the point? Youre transforming a language that does a thing well into a language that does a thing less well than another language. But on the other hand different approaches make things easier to reason about. sometimes the shell approach of baz 1 | bar | foo may make more sense. sometimes it might be a map, sometimes a for loop. So in that sense, a DSL for python type, scripting makes sense.
- pieterbreed 2y ago
  I'm sorry if I touched you on an ouchie. > Its still homoiconic > they can still, and in the case of the linked project, probably are turned into the exact same data structure. 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. The point of homoiconicity is that the data structure representing the code is the code itself. There's no syntax, it just represents itself. It's super simple. A programming language with syntax cannot be homoiconic. This is complexity. > I get your objection insofar as whats the point? "Easy" IS an argument to choose something over something else, but "simple" is a better, stronger argument. Parens syntax is simple. Whitespace syntax is easy, iff you come from/is familiar with a python-style background. We are debating some obscure thing. The point is the argument :) I hope you have a great day.
  - benj111 2y ago
    >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.
  - deleted 2y ago
    [deleted]
  - jlokier 2y ago
    > 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. First, Lisp is not homoiconic by that definition either. If you read "( + 1 2 )" as a Lisp object then print it, you'll get "(+ 1 2)", which is not the same string. We understand that difference in sexp whitespace to be superficial, and superficial can be technically defined, but it's a difference. If you accept that superficial differences are allowed within the definition of homoiconicity, you can define the difference between indententation syntax and sexp syntax to be superficial too, if you want. Second, it's not true that what gets printed has to be the Lisp representation. It depends which print function you use. Homiconicity requires the reader and printer match. If you write a different reader, to accept a different syntax, then you need to use the corresponding printer. If you print_with_new_syntax (a function name I've made up), you get back the original code in its indentation-based form, which makes the pair read_with_new_syntax + print_with_new_syntax homoiconic in the classical Lisp sense. There may be superficial differences, such as if you put in "baz 1 " and get out "bar 1" (missing a space), or "baz" followed by "1" indented on the next line, but as noted above, Lisp sexps have this characteristic too. (Then consider "(+ 1 #-t 2 3)" which in a Lisp that supports #- evaluates to 4. Read that and print it, you'll get "(+ 1 3)", which isn't a superficial difference any more.)
deleted 2y ago
[deleted]
aoeusnth1 2y ago
If the semantics are exactly the same as clojure, can you give me a specific example of what value is lost? Surely the semantics must be different for there to be a loss of tangible expressivity of the language?
vrighter 2y ago
the lisp text representation is not lisp data. Nor is it code. It's just a textual representation of the homioiconic abstract code/data. A different textual encoding does not affect the homoiconicity

benj111 2y ago

(foo (bar (baz 1))) is equivalent to foo bar baz 1 Its still homoiconic they can still, and in the case of the linked project, probably are turned into the exact same data structure. I get your objection insofar as whats the point? Youre transforming a language that does a thing well into a language that does a thing less well than another language. But on the other hand different approaches make things easier to reason about. sometimes the shell approach of baz 1 | bar | foo may make more sense. sometimes it might be a map, sometimes a for loop. So in that sense, a DSL for python type, scripting makes sense.

pieterbreed 2y ago
I'm sorry if I touched you on an ouchie. > Its still homoiconic > they can still, and in the case of the linked project, probably are turned into the exact same data structure. 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. The point of homoiconicity is that the data structure representing the code is the code itself. There's no syntax, it just represents itself. It's super simple. A programming language with syntax cannot be homoiconic. This is complexity. > I get your objection insofar as whats the point? "Easy" IS an argument to choose something over something else, but "simple" is a better, stronger argument. Parens syntax is simple. Whitespace syntax is easy, iff you come from/is familiar with a python-style background. We are debating some obscure thing. The point is the argument :) I hope you have a great day.
- benj111 2y ago
  >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.
- deleted 2y ago
  [deleted]
- jlokier 2y ago
  > 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. First, Lisp is not homoiconic by that definition either. If you read "( + 1 2 )" as a Lisp object then print it, you'll get "(+ 1 2)", which is not the same string. We understand that difference in sexp whitespace to be superficial, and superficial can be technically defined, but it's a difference. If you accept that superficial differences are allowed within the definition of homoiconicity, you can define the difference between indententation syntax and sexp syntax to be superficial too, if you want. Second, it's not true that what gets printed has to be the Lisp representation. It depends which print function you use. Homiconicity requires the reader and printer match. If you write a different reader, to accept a different syntax, then you need to use the corresponding printer. If you print_with_new_syntax (a function name I've made up), you get back the original code in its indentation-based form, which makes the pair read_with_new_syntax + print_with_new_syntax homoiconic in the classical Lisp sense. There may be superficial differences, such as if you put in "baz 1 " and get out "bar 1" (missing a space), or "baz" followed by "1" indented on the next line, but as noted above, Lisp sexps have this characteristic too. (Then consider "(+ 1 #-t 2 3)" which in a Lisp that supports #- evaluates to 4. Read that and print it, you'll get "(+ 1 3)", which isn't a superficial difference any more.)

deleted 2y ago

[deleted]

aoeusnth1 2y ago

If the semantics are exactly the same as clojure, can you give me a specific example of what value is lost? Surely the semantics must be different for there to be a loss of tangible expressivity of the language?

vrighter 2y ago

the lisp text representation is not lisp data. Nor is it code. It's just a textual representation of the homioiconic abstract code/data. A different textual encoding does not affect the homoiconicity