《ruby元编程》有奖试读中！（获奖名单已公布）

starwing83

回复 70# OwnWaterloo


    我是说在这个帖子里是谁提出来的……泥潭啊，我们不是已经有结论了么，还拿出来说= =

对，我就是很质疑lisp的“无语法”，我觉得语法还是好的，重点是多轻，你看lisp都有'a这种语法，其实轻语法是好的，问题是得轻到什么程度，水至清则无鱼啊

OwnWaterloo

回复 67# starwing83

关于模式匹配库。
我知道lisp那种库，怎么说呢…… 就是用s-exp而非文本来表示正则表达式。 也许是因为复杂的正则表达式很难读写的原因。

同时，关于元编程的重型使用。 on lisp里有一个整个程序就是一个宏的例子。
也许里面会发明这样的轮子， 或者cl里面本身就有。

而且，以xmatch为例是在比较库与语言了。你还分不清这里的区别？
如果你想做，lisp难道会比xmatch更困难？
如果真要将库与语言混合在一起比较， lua相比许多语言都是完败。

关于ct亲民，还有内建数据结构表示ast。
前面你自己也发觉了，重语法依然是行不通的。 lisp不是为了亲民， 而是语法轻到极致、 统一到了极致就是这个样子。
这语法就这么让人受不了？  我一开始就是冲着个去的， 习惯了（2-3个月）也没觉得怎样。
所谓的轻语法， 也就是将少量lisp函数做成了关键字， 将算术运算改为中缀。
操作ast不如lisp一致， 直接写代码又不如重语法的短…… 不上不下的……

OwnWaterloo

回复 71# starwing83

'a是因为它太重要了，这是code与data的分界线，比+-*/什么的重要多了……
`a是一种模板技术，大部分东西都保持原样，只对小部分进行求值，其实这都不需要给你解释的……

需要给你解释的是`a与'a不一样， `a一开始貌似真的是内建的， 所以才有了一个单独的语法。
一种实现方式， `a只是一个marker， reader只需要将它转换为 (backquote a) 什么的， 剩下的交给evaluator。
另一种实现方式， `a的工作是由reader完成， 很重型， 而且需要read期的运行环境。

clisp是从后者改到前者（于是cl标准很有可能连`a该怎么实现都没规定）， clojure目前都还是在用后者， 前者是一个计划。

#'f 是因为lisp-2……  要想传入函数， (symbol-function 'f) 确实太……
lisp-1就不需要这种东西……

#(+ %1 %2) 也许是因为 (lambda (x y) (+ x y)) 写起来实在是太糟糕了……  而clojure很明确的是函数式语言，也很明确地不是命令式或OO语言。


对lisp来说，这些比算术运算重要得多。什么类型的代码都需要使用， 但算术运算不是。
其实#(+ %1 %2) 我觉得都可以在局部用用就行了……

infix就那么重要么…… scheme有一些infix扩展，不知道有没有被标准化……

OwnWaterloo

貌似……  之前还是在ruby vs lisp……  后面就彻底歪楼了
被删贴也认了……

zhlong8

lisp 可以控制 reader 来改变语法，不用括号改成 Python 范也可以

另外 lisp 体积大很大原因是因为它是用 lisp 本身实现的吧。单 racket 的编译器的字节码都 1.1 M，语言提供的基本功能都要 4M 的字节码，而这些东西 Ruby 直接用 C 就实现了，小是自然的。

zhlong8

突然发现你们两个可以拿 Ruby 版的 2月发贴奖励了吧

starwing83

回复 75# zhlong8


    chicken就是ow说的生成C代码作为可移植汇编的……可是生成的C代码就有十几M，编译出来的exe（不是字节码）基础的就有5M+……这个……

zhlong8

starwing83 发表于 2012-03-01 14:31
回复 75# zhlong8

你说的对，而且字节码可能还比 C 省空间才对。那到底哪里大啊，明明有那么多很小的实现

coffee777

初学者，来围观一下

starwing83

回复 78# zhlong8


    很小的实现通常直接执行cons，不会涉及字节码，也就是说，几乎没法做优化，速度已经定了（完全没有优化的余地了）。

大的实现通常精力放在了两个地方：cons程序到字节码（或C汇编）的转换，以及库。注意我上面提到的，Lisp几乎是没办法直接应用字节码的，因为如果严格说来，不完全优化的话，它的字节码就一个：OP_CALL，而这其实就已经是在直接执行cons了，因此完全没有优化的必要。而为了能够应用字节码，通常一些函数是不让动的，或者是编译器自动跟踪你有没有动，只要你有动的可能就不能字节码。这样编译器的实现可能就很大了。就像你说的，如果我改了全局环境，无论在哪儿都会导致全部的源代码，包括包含的文件，无法直接编译，也就是说这种检测本身就必须在编译之前做，而检测的时候无疑也是必须要编译一遍的。总之，这种算法本身的复杂度，加上编译的复杂度，再加上continuation等技术在语言层的复杂度，真的想不大都难的。

lisp如果完全自由，就只有两种可能，要么是小并效率底下的实现（如tinyscheme），要么就是效率非常高但是体积庞大的实现（各种其他实现，如racket）。这就是由lisp本身简单的概念造成的。

我记得我举过一个例子，求N个元素的所有组合，每个元素有选或者不选两个状态。一种方法是dfs，但是有一种特别优雅的方法：我从1迭代到2^N，将每个数字的bit值取出来，对应N个元素的位是1则是选，是0则是不选。这个算法是不是很优雅？而且写起来超级简单，lisp就是这第二个优雅的方法，概念简洁，编码简单，充满了优雅的美感——但是，这种方法同时杜绝了任何剪枝啊什么的优化方式，除了优雅以外，几乎完全没办法在进一步的需求下提供任何的优化。因此我个人认为这是一种为了优雅误入歧途的表现。lisp就是这样的。