【求教】我最近在写一个解释器。请道友们谈谈看有哪些优秀的语言特性。

Programming
22

给你们推荐点有意思的

1 个赞
23

能不能把解释器相关知识科普一下？有blog吗？能否发出来，我想看看。

24

我希望有门语言开发的时候是解释型的，发布的时候是编译型的，开发的时候直接支持源代码监控，软件热更新

25

common lisp 完美符合你的需求（

26

补充一个 @coco24 在知乎上的回答

27

请问 Chez Scheme 支持这些特性吗？

28

对 专家 而言,不支持或者对支持不满意,可以自己实现一个, 所以支不支持不重要

29

我可否这么理解：这些特性或许没有被原生支持，但是如果用 Scheme 从零实现这个特性的话，要比其他语言容易太多（当然也需要一定水平： 专家）。

30

不知道, 我不会lisp, 不过有那么多大佬喜欢lisp肯定是有它的优点

31

我不懂chez scheme，不过common lisp从设计上就很注重交互式的开发：

Development in Common Lisp is interactive. There’s no separate compile/run/debug cycle. Instead of that, the program is developed while it runs. Compilation is incremental, and functions can be created and updated on the fly. As the program is running, all objects are available and can be inspected all the time. This is much more than a simple REPL; the whole environment, from the IDE to the language is prepared for this type of development.

scheme 在这方面大概是不如 common lisp 的。非 lisp 系或许你应该看看 smalltalk。

32

明白啦 （zsbd

33

首先，主流的几个 Common Lisp 如 SBCL 是纯编译器实现，简单地说就是 JIT。Chez 虽然另外保留了解释器实现，目前主要用的也是纯编译实现，也就是快的编译器可以假装自己是解释器

其次，快的解释器不需要编译，比如发明 K 语言的 Arthur Whitney 就曾写过一个 C 的子集的解释器，程序运行速度比 GCC 编译出来的 binary 还快，还不用编译。他写的 K 语言实现也是类似结构的纯解释器，是做大量数据分析的最快选择。

所以分解释和编译是没啥实际意义的。

2 个赞
34

我不大相信解释性语言比编译语言还快，解释语言毕竟有解析的代价的，也许某些情况下能接近，但是还是有额外代价的，虽然现在的jit可以只解析一次然后一直调用缓存，但是一方面没有c/c++这样大幅度的编译期优化，另一方面解释型程序本身的体积肯定是比编译的二进制要大很多的，你看现在web端的webassembly就是为了解决jit的缺陷产生的

35

如果你了解过 APL 系语言的解释器设计的话，就会知道有完全抛弃解析语法树，把未经任何处理的源代码本身看成 byte code 的设计，解释器比编译器快的来源就在这里。

你低估了编译后的代码膨胀，举个最简单的例子，用 C 写个 Hello World 程序，哪怕开最小优化，编译出来的结果肯定比代码文件大，要是 C++ 的话代码生成用的一多编译出来能不大吗？所谓解释型程序体积大的主要来源其实是注释和空白，还有过长的变量名，真要在意这，这些是可以用预处理器去除的，在 JS 也是实践中的操作

Webassembly 本质上就是这样一种抛弃了AST，注释和空格和变量名的解释性语言（没错它当然是用浏览器附带的解释器运行的），这难道不是更加印证了解释和编译没必要分得太清楚吗

你可能没有注意到我强调的是，解释器好还是编译器好，完全取决于具体实现的质量，而不是因为它是解释器/编译器就一定比另一方优秀，而你所谓两个都带的编程语言显然不见的比编译/解释各自做到极致的好。从常识上来讲，C/C++ 的编译器是相当成熟而且优秀的，但是从更广的范围看，大部分编译型语言的实现质量都远没有到这个程度，哪怕是编译到 C/C++ 的语言，也不可能没有性能损失，更何况是代码写的烂的，所以才有在解释器和编译器之间选择的余地。

36

上面那位说的 “解释型程序本身的体积” 显然是指 源文件+解释器.

37

我本来想写这个的，但是想想觉得还是算了，因为这个还要算上动态链接的库，比如拿 40kb 的 lua 解释器和几 mb 的 libc++ 比，就更是一笔算不清的糊涂帐了。

Again，解释器程序比编译的小，或者反过来，都是可以成立的

1 个赞
38

通常来讲, 解释比编译至少多一道 lexing 的工序吧, 除非解释执行的直接就是手写的字节码 (ELisp 似乎可以手写字节码), webasm 好像就属于这一种

39

APL 系是连 lexing 都不需要做的。当然，这是和常识不一样的论外。

这里插两个完全无关的暴论小故事

  1. 上一个问我说，“APL 用 stack 来实现 parsing，所以是 forth 吗”，的人，被我用“Go 有 coroutine，所以是 Scheme 吗”打发了

  2. 上一个跟我说，他有自信写任何架构的汇编，比 C 编译器编译出来的快的人，被我用 PDP-10 汇编手册打发了

40

你在一个有 GC 的语言里写解释器，理论上就是不需要自己处理 GC 的呀。。。

41

我就是这个意思啊，你把我说的话重复了一遍😂不过我只尝试了纯解释，编译成字节码是不是还能这样就不清楚了