¿En qué sentido son lenguas como Elixir y Julia homoicónicas?

Question

¿En qué sentido son lenguas como Elixir y Julia homoicónicas?

La homoiconicidad en Lisp es fácil de ver:

(+ 1 2)

Es tanto la llamada a la función + con 1, 2 como argumentos, además de ser una lista que contiene +, 1, y 2. Es simultáneamente código y datos.

En un lenguaje como Julia, sin embargo: {[14]]}

1 + 2

Sé que podemos analizar esto en un Expr en Julia:

:(1 + 2)

Y luego podemos obtener el AST y manipularlo:{[14]]}

julia> Meta.show_sexpr(:(1+2)) (:call, :+, 1, 2)

Entonces, nosotros puede manipular el AST de un programa en Julia (y Elixir). Pero ¿son homoicónicos en el mismo sentido que Lisp-es cualquier fragmento de código realmente solo una estructura de datos en el propio lenguaje?

No veo cómo código como 1 + 2 en Julia es, inmediatamente, datos - como cómo (+ 1 2) en Lisp es solo una lista. ¿Sigue siendo homicida, entonces?

24

lisp julia-lang homoiconicity

Author: user2666425, 2015-07-30

Source

1 answers

score 30 · Accepted Answer

En palabras de Bill Clinton, " Depende del significado de la palabra 'es'". Bueno, está bien, no realmente, pero depende de cuál sea el significado de la palabra "homoicónico". Este término es lo suficientemente controvertido como para que ya no digamos que Julia es homoicónica, por lo que puede decidir por sí mismo si califica. En lugar de tratar de definir la homoiconicidad, citaré lo que Kent Pitman (quién sabe una cosa o dos sobre Lisp) dijo en una entrevista de Slashdot de vuelta en 2001:

Me gusta la voluntad de Lisp de representarse a sí mismo. La gente a menudo explica esto como su capacidad de representarse a sí misma, pero creo que eso está mal. La mayoría de los idiomas son capaces de representarse a sí mismos, pero simplemente no tienen la voluntad de hacerlo. Los programas Lisp están representados por listas y los programadores son conscientes de ello. No importaría si hubieran sido arreglos. Sí importa que es la estructura del programa que se representa, y no la sintaxis de caracteres, pero más allá de eso la elección es bastante arbitrario. No es importante que la representación sea la elección Correcta®. Solo es importante que sea una opción común y acordada para que pueda haber una rica comunidad de programas manipuladores de programas que "comercian" en esta representación común.

Tampoco define homoiconicidad – probablemente no quiera entrar en un argumento de definición más que yo. Pero va al meollo del asunto: ¿qué tan dispuesto está un lenguaje a representarse a sí mismo? Lisp es dispuesto en el extremo-ni siquiera se puede evitar: la representación del programa como datos está justo ahí, mirando a la cara. Julia no utiliza la sintaxis de S-expression, por lo que la representación del código como datos es menos obvia, pero no se oculta muy profundamente:

julia> ex = :(2a + b + 1)
:(2a + b + 1)

julia> dump(ex)
Expr
  head: Symbol call
  args: Array(Any,(4,))
    1: Symbol +
    2: Expr
      head: Symbol call
      args: Array(Any,(3,))
        1: Symbol *
        2: Int64 2
        3: Symbol a
      typ: Any
    3: Symbol b
    4: Int64 1
  typ: Any

julia> Meta.show_sexpr(ex)
(:call, :+, (:call, :*, 2, :a), :b, 1)

julia> ex.args[3]
:b

julia> ex.args[3] = :(3b)
:(3b)

julia> ex
:(2a + 3b + 1)

El código de Julia está representado por el tipo Expr (y símbolos y átomos), y aunque la correspondencia entre la sintaxis de la superficie y la estructura es menos obvia inmediatamente, sigue ahí. Y más es importante destacar que la gente sabe que el código es simplemente datos que se pueden generar y manipular, por lo que hay una "rica comunidad de programas de manipulación de programas", como lo puso KMP.

Esto no es solo una presentación superficial del código de Julia como una estructura de datos – así es como Julia representa su código a sí misma. Cuando introduce una expresión en el REPL, se analiza en objetos Expr. Esos objetos Expr se pasan entonces a eval, lo que los "baja" a objetos Expr algo más regulares, que luego se pasan a la inferencia de tipo, todos implementados en Julia. El punto clave es que el compilador utiliza exactamente la misma representación de código que usted ve. La situación no es tan diferente en Lisp. Cuando nos fijamos en el código Lisp, en realidad no se ven los objetos de la lista-que solo existen en la memoria de la computadora. Lo que se ve es una representación textual de literales de lista, que el intérprete Lisp analiza y convierte en objetos de lista que luego evalúa, al igual que Julia. Sintaxis de Julia puede ser visto como una representación textual para Expr literales – el Expr simplemente pasa a ser una estructura de datos algo menos general que una lista.

No conozco los detalles, pero sospecho que Elixir es similar, tal vez José lo haga.

Véase también: