- 论坛徽章:
- 2
|
回复 80# starwing83
>> chicken就是……可是生成的C代码就有十几M,编译出来的exe(不是字节码)基础的就有5M+……
这货貌似是用continuation passing style实现的。
任何语言这么写都会很乱,不知道haskell会如何……貌似它也是这么实现的……,C肯定更乱……
至于大,我想还是前面提到的,没能去掉不用的runtime。
>> 很小的实现通常直接执行cons,不会涉及字节码
sbcl(windows, 不依赖外部编译器, 10M), ecl(10M), gcl(40+M,带gcc!), gambit(7m), plt(racket,mz的关系很混乱,我记不清了…… 200M,但貌似带了许多库) 它与都是产生本地代码。
clisp(30-M,很多库)/guile(Windows下没有……)是虚拟机。
全都比python小。
别和lua比, lua是个裸的好吗…… 它那标准库能做个啥……
>> 而为了能够应用字节码,通常一些函数是不让动的
http://en.wikipedia.org/wiki/Com ... pture_and_shadowing
Common Lisp solves the problem of the shadowing of standard operators and functions by forbidding their redefinition. Because it redefines the standard operator DO, the preceding is actually a fragment of non-conforming Common Lisp, which allows implementations to diagnose and reject it.
http://en.wikipedia.org/wiki/Scheme_(programming_language)#Redefinition_of_standard_procedures
In Scheme, procedures are bound to variables. At R5RS the language standard formally mandated that programs may change the variable bindings of built-in procedures, effectively redefining them.
In R6RS every binding, including the standard ones, belongs to some library, and all exported bindings are immutable. (R6RS sec 7.1)[4] Because of this, redefinition of standard procedures by mutation is forbidden.
>> 这就是由lisp本身简单的概念造成的。
我也不是第一次说了…… 这种简单概念是用来解释(explain)lisp,虽然有一些实现直接就用来解释(interpret)了……
自己看上面引用的,以及用用前面提到的那些小的实现吧……
我是不太喜欢用它们,与lua的理由一样,干不了活。 如果有什么严肃认真的东西要做也许才会去考虑这些小的实现。
>> 我记得我举过一个例子...
你那个例子我没看得很懂。 如果考虑了缓式求值呢?
产生所有解与在这些解上剪枝, 如果是严格求值, 就必须写在一起。
而缓式求值就可以将这两个过程解耦, 并希望能达到严格求值中手写的相当的效率。 至于是否能达到我也没信心……
我的意思是说,技术发展虽然缓慢,但还是在发展。
gc被认为很浪费, 现在不也习以为常了?
词法作用域曾经被认为不可能高效实现 —— 多少牛人都曾经有过这样的判断 —— 但他们也都错了。
还有至少写on lisp那个人,还有实现p啥啥lisp那个人,根本不把运行时效率当回事……
on lisp那个说: 每一代人都会做上一代人看来很浪费的事。
他实现的那个arc…… 他自己都承认一开始只是勉强能用(用clisp实现的解释器,clisp自己又在虚拟机上)。 不知道现在arc是不是只有list of char没有string……
也许这些家伙觉得现在的lisp已经比原来快得多了, 还优化个毛啊……
我说…… 要不去别的版块闹? 连同上面的zhlong8同学…… 不过CU木有lisp只有个functional版块就是了……
这可是ruby版…… 主题是某本书的试读…… 这赤果果的歪楼不科学啊……
|
|