像Elixir和Julia Julianiconic这类语言在什么意义上是? [英] In what sense are languages like Elixir and Julia homoiconic?

问题描述

在Lisp中的同渗性很容易看到:

Homoiconicity in Lisp is easy to see:

(+ 1 2)

既是使用1，2作为参数对+的函数调用，又是包含+，1和2的列表.同时是代码和数据.

is both the function call to + with 1, 2 as arguments, as well as being a list containing +, 1, and 2. It is simultaneously both code and data.

不过，使用朱莉亚这样的语言:

In a language like Julia, though:

1 + 2

我知道我们可以将其解析为Julia中的Expr:

I know we can parse this into an Expr in Julia:

:(1 + 2)

然后我们可以获取AST并对其进行操作:

And then we can get the AST and manipulate it:

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

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

因此，我们可以在Julia(和Elixir)中操纵程序的AST.但是，它们与Lisp的含义相同吗?任何代码段真的只是语言本身的数据结构吗?

So, we can manipulate a program's AST in Julia (and Elixir). But are they homoiconic in the same sense as Lisp- is any snippet of code really just a data structure in the language itself?

我看不到Julia中的1 + 2这样的代码如何立即成为数据，就像Lisp中的(+ 1 2)只是一个列表一样.那么，它仍然是谐音的吗?

I don't see how code like 1 + 2 in Julia is, immediately, data- like how (+ 1 2) in Lisp is just a list. Is it still homiconic, then?

推荐答案

用比尔·克林顿(Bill Clinton)的话来说，这取决于'是'这个词的含义是什么".好吧，不是真的，但这确实取决于"homoiconic"一词的含义.这个词有足够的争议，我们不再说朱莉娅是同性恋.因此您可以自己决定是否符合条件.我将尝试引用肯特·皮特曼(谁知道某事或关于Lisp的两个)在 Slashdot访谈早在2001年:

In the words of Bill Clinton, "It depends upon what the meaning of the word 'is' is". Well, ok, not really, but it does depend on what the meaning of the word "homoiconic" is. This term is sufficiently controversial that we no longer say that Julia is homoiconic – so you can decide for yourself whether it qualifies. Instead of trying to define homoiconicity, I'll quote what Kent Pitman (who knows a thing or two about Lisp) said in a Slashdot interview back in 2001:

我喜欢Lisp表示自己的意愿.人们经常将其解释为代表自己的能力，但我认为这是错误的.大多数语言都有能力代表自己，但是他们根本没有意愿. Lisp程序由列表表示，程序员意识到这一点.它是否是数组都没关系.所代表的是程序结构，而不是字符语法，这很重要，但除此之外，选择是相当随意的.表示为Right®选择并不重要.重要的是，这是一个共同的，商定的选择，以便可以有一个丰富的程序操纵程序社区，以这种通用表示形式进行交易".

I like Lisp's willingness to represent itself. People often explain this as its ability to represent itself, but I think that's wrong. Most languages are capable of representing themselves, but they simply don't have the will to. Lisp programs are represented by lists and programmers are aware of that. It wouldn't matter if it had been arrays. It does matter that it's program structure that is represented, and not character syntax, but beyond that the choice is pretty arbitrary. It's not important that the representation be the Right® choice. It's just important that it be a common, agreed-upon choice so that there can be a rich community of program-manipulating programs that "do trade" in this common representation.

他也没有定义同源性–他可能不想像我一样进入定义性论点.但是他直言不讳:一种语言代表自己的意愿如何? Lisp愿意在极端情况下–您甚至无法避免:程序的表示就像数据就在那儿一样，直视您. Julia不使用S-expression语法，因此代码作为数据的表示不太明显，但隐藏的并不深:

He doesn't define homoiconicity either – he probably doesn't want to get into a definitional argument any more than I do. But he cuts to the heart of the matter: how willing is a language to represent itself? Lisp is willing in the extreme – you can't even avoid it: the representation of the program as data is just sitting right there, staring you in the face. Julia doesn't use S-expression syntax, so the representation of code as data is less obvious, but it's not hidden very deep:

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)

Julia代码由Expr类型(以及符号和原子)表示，尽管表面语法和结构之间的对应关系虽然不太明显，但仍然存在.更重要的是，人们知道代码只是可以生成和操纵的数据，因此，正如KMP所说的那样，这里有一个丰富的程序操纵程序社区".

Julia code is represented by the Expr type (and symbols and atoms), and while the correspondence between the surface syntax and the structure is less immediately obvious, it's still there. And more importantly, people know that code is simply data which can be generated and manipulated, so there is a "rich community of program-manipulating programs", as KMP put it.

这不仅仅是将Julia代码作为数据结构的表述-这就是Julia自身如何表示其代码的方式.当您在REPL中输入表达式时，它将被解析为Expr对象.然后将那些Expr对象传递给eval，将它们降低"到更常规的Expr对象，然后将其传递给类型推断，所有实现都

This is not just a superficial presentation of Julia code as a data structure – this is how Julia represents its code to itself. When you enter an expression in the REPL, it is parsed into Expr objects. Those Expr objects are then passed to eval, which "lowers" them to somewhat more regular Expr objects, which are then passed to type inference, all implemented in Julia. The key point is that the compiler uses the exact the same representation of code that you see. The situation is not that different in Lisp. When you look at Lisp code, you don't actually see list objects – those only exist in the computer's memory. What you see is a textual representation of list literals, which the Lisp interpreter parses and turns into list objects which it then evals, just like Julia. Julia's syntax can be seen as a textual representation for Expr literals – the Expr just happens to be a somewhat less general data structure than a list.

我不知道细节，但我怀疑Elixir很相似-也许José会加入.

I don't know the details, but I suspect that Elixir is similar – maybe José will chime in.

更新(2019)

在过去的4年多的时间里，我对此进行了更多的思考，我认为Lisp和Julia之间的主要区别在于:

Having thought about this more for the past 4+ years, I think the key difference between Lisp and Julia is this:

• 在Lisp中，代码的语法与用于表示该代码的数据结构的语法相同.
• 在Julia中，代码的语法与表示该代码的数据结构的语法完全不同.

为什么这很重要?在支持Julia的方面，人们喜欢事物的特殊语法，并且经常发现S-expression语法不方便或令人不愉快.在亲Lisp方面，当您尝试生成(表示代码)的数据结构的语法与通常编写的代码的语法相同时，找出如何正确进行元编程要容易得多. .这就是为什么当人们尝试在Julia中编写宏时最好的建议之一就是执行以下操作:

Why does this matter? On the pro-Julia side, people like special syntax for things and often find S-expression syntax inconvenient or unpleasant. On the pro-Lisp side, it's much easier to figure out how to do metaprogramming correctly when the syntax of the data structure you're trying to generate (to represent code) is the same as the syntax of the code that you would normally write. This is why one of the best pieces of advice when people are trying to write macros in Julia is to do the following:

1. 写一个您希望宏生成的代码类型的例子
2. 在该代码上调用Meta.@dump，将其视为数据结构
3. 编写代码以生成该数据结构-这就是您的宏.

1. Write an example of the kind of code you want your macro to generate
2. Call Meta.@dump on that code to see it as a data structure
3. Write code to generate that data structure—this is your macro.

在Lisp中，您不必执行步骤2，因为代码的语法已经与数据结构的语法相同. Julia中有准引用(用Lisp讲)quote ... end和:(...)构造，它们使您可以使用代码语法构造数据结构，但仍不像让它们首先使用相同的语法那样直接.

In Lisp, you don't have to do step 2 because syntax for the code is already the same as the syntax for the data structure. There are the quasiquoting (in Lisp speak) quote ... end and :(...) constructs in Julia, which allow you to construct the data structures using code syntax, but that's still not as direct as having them use the same syntax in the first place.

另请参见:

• https://docs.julialang.org/en/v1/manual/元编程/
• 什么是符号"?在朱莉娅?

• https://docs.julialang.org/en/v1/manual/metaprogramming/
• What is a "symbol" in Julia?

这篇关于像Elixir和Julia Julianiconic这类语言在什么意义上是?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！