3 ms·

Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.

by strmpnk 11y ago

davelnewton 11y ago
I see; I thought it compiled to BEAM code directly. I'd wonder then if there's anything representable in the Erlang AST that can't be represented by Erlang itself; it doesn't look like it so far.
- klibertp 11y ago
  There's not - see docs for parse transforms. Erlang is homoiconic in the sense that it's parse tree is its own valid data-structure literal. This is also true for Elixir. The difference is the `quote` and `unquote` macros and a simpler parse tree format in Elixir, which makes meta-programming much easier than in Erlang from what I understand.
  - nox_ 11y ago
    I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.
    - flackjap 11y ago
      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 11y ago
        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 11y ago
        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 11y ago
        > 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.

Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.

by strmpnk 11y ago

Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.

I see; I thought it compiled to BEAM code directly. I'd wonder then if there's anything representable in the Erlang AST that can't be represented by Erlang itself; it doesn't look like it so far.

klibertp 11y ago
There's not - see docs for parse transforms. Erlang is homoiconic in the sense that it's parse tree is its own valid data-structure literal. This is also true for Elixir. The difference is the `quote` and `unquote` macros and a simpler parse tree format in Elixir, which makes meta-programming much easier than in Erlang from what I understand.
- nox_ 11y ago
  I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.
  - flackjap 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
        > 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.