免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: send_linux

《ruby元编程》有奖试读中!(获奖名单已公布) [复制链接]

论坛徽章:
4
狮子座
日期:2013-08-20 10:12:24午马
日期:2013-11-23 18:04:102015年辞旧岁徽章
日期:2015-03-03 16:54:152015亚冠之德黑兰石油
日期:2015-06-29 18:11:11
发表于 2012-03-01 11:58 |显示全部楼层
回复 70# OwnWaterloo


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

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

论坛徽章:
2
青铜圣斗士
日期:2015-11-26 06:15:59数据库技术版块每日发帖之星
日期:2016-07-24 06:20:00
发表于 2012-03-01 12:10 |显示全部楼层
回复 67# starwing83

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

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

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

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

论坛徽章:
2
青铜圣斗士
日期:2015-11-26 06:15:59数据库技术版块每日发帖之星
日期:2016-07-24 06:20:00
发表于 2012-03-01 12:28 |显示全部楼层
回复 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扩展,不知道有没有被标准化……

论坛徽章:
2
青铜圣斗士
日期:2015-11-26 06:15:59数据库技术版块每日发帖之星
日期:2016-07-24 06:20:00
发表于 2012-03-01 12:46 |显示全部楼层
貌似……  之前还是在ruby vs lisp……  后面就彻底歪楼了
被删贴也认了……

论坛徽章:
46
15-16赛季CBA联赛之四川
日期:2018-03-27 11:59:132015年亚洲杯之沙特阿拉伯
日期:2015-04-11 17:31:45天蝎座
日期:2015-03-25 16:56:49双鱼座
日期:2015-03-25 16:56:30摩羯座
日期:2015-03-25 16:56:09巳蛇
日期:2015-03-25 16:55:30卯兔
日期:2015-03-25 16:54:29子鼠
日期:2015-03-25 16:53:59申猴
日期:2015-03-25 16:53:29寅虎
日期:2015-03-25 16:52:29羊年新春福章
日期:2015-03-25 16:51:212015亚冠之布里斯班狮吼
日期:2015-07-13 10:44:56
发表于 2012-03-01 13:38 |显示全部楼层
lisp 可以控制 reader 来改变语法,不用括号改成 Python 范也可以

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

论坛徽章:
46
15-16赛季CBA联赛之四川
日期:2018-03-27 11:59:132015年亚洲杯之沙特阿拉伯
日期:2015-04-11 17:31:45天蝎座
日期:2015-03-25 16:56:49双鱼座
日期:2015-03-25 16:56:30摩羯座
日期:2015-03-25 16:56:09巳蛇
日期:2015-03-25 16:55:30卯兔
日期:2015-03-25 16:54:29子鼠
日期:2015-03-25 16:53:59申猴
日期:2015-03-25 16:53:29寅虎
日期:2015-03-25 16:52:29羊年新春福章
日期:2015-03-25 16:51:212015亚冠之布里斯班狮吼
日期:2015-07-13 10:44:56
发表于 2012-03-01 13:46 |显示全部楼层
突然发现你们两个可以拿 Ruby 版的 2月发贴奖励了吧

论坛徽章:
4
狮子座
日期:2013-08-20 10:12:24午马
日期:2013-11-23 18:04:102015年辞旧岁徽章
日期:2015-03-03 16:54:152015亚冠之德黑兰石油
日期:2015-06-29 18:11:11
发表于 2012-03-01 14:31 |显示全部楼层
回复 75# zhlong8


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

论坛徽章:
46
15-16赛季CBA联赛之四川
日期:2018-03-27 11:59:132015年亚洲杯之沙特阿拉伯
日期:2015-04-11 17:31:45天蝎座
日期:2015-03-25 16:56:49双鱼座
日期:2015-03-25 16:56:30摩羯座
日期:2015-03-25 16:56:09巳蛇
日期:2015-03-25 16:55:30卯兔
日期:2015-03-25 16:54:29子鼠
日期:2015-03-25 16:53:59申猴
日期:2015-03-25 16:53:29寅虎
日期:2015-03-25 16:52:29羊年新春福章
日期:2015-03-25 16:51:212015亚冠之布里斯班狮吼
日期:2015-07-13 10:44:56
发表于 2012-03-01 15:51 |显示全部楼层
starwing83 发表于 2012-03-01 14:31
回复 75# zhlong8
你说的对,而且字节码可能还比 C 省空间才对。那到底哪里大啊,明明有那么多很小的实现

论坛徽章:
0
发表于 2012-03-01 16:02 |显示全部楼层
初学者,来围观一下

论坛徽章:
4
狮子座
日期:2013-08-20 10:12:24午马
日期:2013-11-23 18:04:102015年辞旧岁徽章
日期:2015-03-03 16:54:152015亚冠之德黑兰石油
日期:2015-06-29 18:11:11
发表于 2012-03-01 17:15 |显示全部楼层
回复 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就是这样的。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP