[pieterbreed]

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.

[aoeusnth1]

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]

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]

(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]

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.

[lolinder]

> I'm sorry if I touched you on an ouchie.

In case you're not a first-language English speaker: the wording here implies that they're having a childish emotional reaction to what you said, which (if intentional) is an entirely inappropriate method of discourse, especially when all they did was give a very reasonable and level-headed critique of your definition of homoiconicity (that it's a property of the internal representation, not the external syntax).

[benj111]

>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.

[jlokier]

> 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.)

[kazinator]

"Homoiconic" means that a program's definitions are stored in a textual form which can be re-edited at run time. Bash is homoiconic because you can type "set" to see all the function definitions in source code form, and edit them via copy-paste. Line numbered BASIC interpreters are likewise homoiconic. The program is held in memory in lightly tokenized form; any line of it can be recalled and edited.

That's how the originator of the term "homoiconic" defined it.

[nothrabannosir]

Sexpressions are syntax for linked lists. You can encode a linked list in other ways and as long as you have a reader and printer for it , you could implement lisp on top of it , and it would be homoiconic.

As a very simple example: replace the () with []

As a slightly more complex example: json. (With support for symbols if necessary but that’s orthogonal—you get the idea)

And from there we can go to: yaml.

Lo: we have a white space sensitive homoiconic language :)

[kaba0]

But it's not itself, it's an array of characters. It's AST can be represented as simply as a recursive list data structure (with a head and a tail), but I think this is a bit over-mysticized.

[dustingetz]

macros still work yo

my text editor represents sexprs as pixels, macros still work when src is viewed in GUI editors too, regardless of font, and even when i have my glasses on

[gsbcbdjfncnjd]

Give it a rest.