[flackjap]

I concur -> In computer programming, homoiconicity (from the Greek words homo meaning the same and icon meaning representation) 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. Wiki

[klibertp]

Every language's syntax internal representation can be inferred by reading it's text layout. It's what parsers do and people can, too.

How "similar" internal representation needs to be to its textual version to be homoiconic is subjective.

In Erlang an expression:

    2+3.

yields this AST:

    {op,1,'+',{integer,1,2},{integer,1,3}}

You can strip line and type annotations (you could also easily add them to the Prolog example below), which will get you:

    {'+', 2, 3}

If you scroll down the Wiki page you cite, you'll see an example in Prolog, where this:

    X is 2*5

yields AST of this shape:

    is(_, *(2, 5))

The important similarity here is that all elements of ASTs are still first class objects in the language. You can manipulate them in their raw form with the same functions you'd use for manipulating any other data. In other words, once you have an AST, you don't need to evaluate it, it's enough to just read it.

This is not true for Python. An expression:

    2+3

yields:

    Expression(body=BinOp(left=Num(n=2), op=Add(), right=Num(n=3)))

An AST here cannot be manipulated in its raw form here. To manipulate it - the representation itself - you'd have to parse it again or evaluate it to use special methods on AST objects.

So this is the practical definition of homoiconicity I came up with. You are of course free to disagree. I'm stressing "practical" here, because what I'm interested in is how easy it is to manipulate the AST to write macros. Homoiconicity for the sake of homoiconicity is of no interest to me.

PS. BTW, maybe I should base my argument on Lisp instead of Prolog. If you read the Wikipedia page carefully you'll see the part on Lisp says the same thing I do above.

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