在Lisp中，代码就是数据.这有什么好处? [英] In Lisp, code is data. What benefit does that provide?

问题描述

在Lisp中，任何程序的代码实际上都是有效的数据结构.例如，这将一个和两个加在一起，但它也是三个项目的列表.

In Lisp, any program's code is actually a valid data structure. For example, this adds one and two together, but it's also a list of three items.

(+ 1 2)

这提供了什么好处?使用其他语言，这使您能够做到这一点是什么不可能的事情，并且/或者不太优雅?

What benefit does that provide? What does that enable you to do that's impossible and/or less elegant in other languages?

推荐答案

要使代码表示更为清晰，请考虑在每一种语言中，代码都是数据:您需要的只是字符串. (也许还有一些文件操作.)考虑如何帮助您模仿具有宏系统的Lisp好处是一个启发的好方法.如果您尝试实现这样的宏系统，那就更好了.您将遇到具有结构化表示形式而不是字符串平坦度的优点，需要先运行转换并定义语法钩子"以告诉您将其应用到何处等优点.

To make things a little clearer with respect to code representation, consider that in every language code is data: all you need is strings. (And perhaps a few file operations.) Contemplating how that helps you to mimic the Lisp benefits of having a macro system is a good way for enlightenment. Even better if you try to implement such a macro system. You'll run into the advantages of having a structured representation vs the flatness of strings, the need to run the transformations first and define "syntactic hooks" to tell you where to apply them, etc etc.

但是，在所有这些内容中您将看到的主要是，宏本质上是编译器挂钩的便利工具-挂钩在新创建的关键字上的挂钩.因此，真正唯一需要的是某种使用户代码与编译器代码交互的方法.扁平字符串是一种实现方法，但是它们提供的信息很少，因此宏编写器只剩下从头开始实现解析器的任务.另一方面，您可以公开一些内部编译器结构，例如预先解析的AST树，但是这些树往往公开太多的信息，以至于 都不方便，这意味着编译器需要以某种方式能够解析您打算实现的新语法扩展. S表达式是后者的一个很好的解决方案:由于语法是统一的，因此编译器可以解析任何内容.它们也是前者的解决方案，因为它们是简单的结构，并受到语言的广泛支持，可以将它们拆开并以新的方式重新组合.

But the main thing that you'll see in all of this is that macros are essentially a convenient facility for compiler hooks -- ones that are hooked on newly created keywords. As such, the only thing that is really needed is some way to have user code interact with compiler code. Flat strings are one way to do it, but they provide so little information that the macro writer is left with the task of implementing a parser from scratch. On the other hand, you could expose some internal compiler structure like the pre-parsed AST trees, but those tend to expose too much information to be convenient and it means that the compiler needs to somehow be able to parse the new syntactic extension that you intend to implement. S-expressions are a nice solution to the latter: the compiler can parse anything since the syntax is uniform. They're also a solution to the former, since they're simple structures with rich support by the language for taking them apart and re-combining them in new ways.

但是，那当然不是故事的结局.例如，比较CL中的普通符号宏和Scheme实施中的卫生宏比较很有趣:通常通过向表示的数据中添加更多信息来实现这些宏，这意味着您可以使用这些宏系统做更多的事情. (您还可以使用CL宏来做更多的事情，因为额外的信息也是可用的，但不是将其作为语法表示的一部分，而是将其作为额外的环境参数传递给宏.)

But of course that's not the end of the story. For example, it's interesting to compare plain symbolic macros as in CL and hygienic macros as in Scheme implementations: those are usually implemented by adding more information to the represented data, which means that you can do more with those macro system. (You can also do more with CL macros since the extra information is also available, but instead of making it part of the syntax representation, it's passed as an extra environment argument to macros.)

这篇关于在Lisp中，代码就是数据.这有什么好处?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！