[davelnewton]

Homoiconicity specifically means that the primary representation of the language is a datatype in the language itself; Erlang isn't that.

I don't find it particularly subjective, it's just what it means. According to what you're saying any language that can be parsed and manipulated by the language is homoiconic, since the AST can be represented by types available in the language, no?

[klibertp]

> Homoiconicity specifically means that the primary representation of the language is a datatype in the language itself; Erlang isn't that.

Literal datatype.

And please, prove it to me that "Erlang isn't that". My examples above indicate quite clearly that yes, it is.

> I don't find it particularly subjective,

I was referring to the word "similar" which appeared in the definition of homoiconicity given by flackjap.

> since the AST can be represented by types available in the language, no?

Yes, if the datatypes used in AST representation have literal forms in the language. No otherwise.

[davelnewton]

You claim any language that can represent its AST using that language's literal datatypes is homoiconic?! No. I can represent an AST in array literals in essentially any language, and quite a few using object/hash notation. That alone does not make a language homoiconic. See, for example, the lengthy thread here: http://c2.com/cgi/wiki?HomoiconicExampleInJava

[klibertp]

There's another constraint, as seen in the definition of homoiconicity from Wikipedia. I'll paste it once again:

> In computer programming, homoiconicity [...] is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. If a language is homoiconic, it means that the language text has the same structure as its abstract syntax tree (i.e. the AST and the syntax are isomorphic). This allows all code in the language to be accessed and transformed as data, using the same representation.

As I noted, a similarity is subjective, but I never claimed that it's not needed as a criterion. So, what I claim is that homoiconicity happens when the AST representation consists of only literal datatypes of the language AND the AST structure is "similar" to the original code.

That's it. And also:

> I can represent an AST in array literals in essentially any language

I doubt it, but that's irrelevant. Had you done it you'd essentially reimplement the language of your choice and then we're not talking about that language in general anymore, but about your implementation. What you say here is that "every language can be made homoiconic given appropriate AST implementation". And that's probably true, although I suspect it gets too hard to do in practice for more complex syntaxes.

May I ask where are you getting your strong convictions about homoiconicity from? If you read the Wiki page you'll notice the use of less than precise words, like "similar" or "Languages which are considered homoiconic include" and so on. The concept itself is not as clear-cut as you seem to believe and it's mostly defined by examples.

Also, you still didn't provide a convincing argument that Erlang is not homoiconic; you only claimed that "it isn't" and moved on.

EDIT: as an example of how subjective homoiconicity is take a look at Julia. Listed on the wikipedia as homoiconic, here are the details: http://docs.julialang.org/en/latest/manual/metaprogramming/ - if Julia is homoiconic, then Erlang and Elixir are too. And Haxe, and Dylan. Are they? I don't know, I'm not going to argue about this. As I said, homoiconicity is only interesting as a way of simplifying macro creation; any more discussion is honestly useless to me.