站在月亮看地球——牛逼的新语言 MoonScript

starwing83

回复 182# OwnWaterloo


    你可以说明这两种form不一样，正如同+和add不一样，但是这不能说明Lisp对这两种不一样的form的求值策略不一样，正如就算+和add不一样，你也不能说明Lisp对这两种不一样的函数的求值策略不一样。这才是我们讨论的东西。

captivated

{:3_189:}

马上盖到200+了
这证明叔叔的预见是非常准确的

看来此帖又要成为坑 o(∩∩)o...
哈哈 OW是无敌的！叔叔真的没粉错淫啊！

可惜这贴中间的各种乱入少了点 嗯

OwnWaterloo

shit我不和你争。首先世界上肯定有美的东西。我不认为“编程本身就是shit”（这句话和你的原话“编程就是处理shit”有不同吗？）我觉得编程至少是有美好的东西的。注意，“有”美好的东西，意味着美好的东西总是占shit的百分比，如果这个比例是100%，我就认为它没有shit，或者放松一点（Lua内部实现也的确是有很细微的操蛋的地方，你必须得承认），如果有90%是美的，我就认为不是shit，所以我觉得lua不是shit。无论实现还是语言。shit的部分都没超过10%。
starwing83 发表于 2011-08-19 18:15

我再强调一下， 157楼的shit的含义是：猥琐的细节与妥协。 这是普遍存在的。
我对它们的看法也与你不同： 不会因为90%是美好的就忽略它们的存在。
貌似你又在支持我的观点？ 编程就是产生shit， 只是量的不同。  这与编程就是在产生美好， 只是量的不同， 真有什么区别吗？

    我真的很佩服你了。我说的“分析函数体”是个比方，是说明你同样有可能分析不到函数体从而函数也会分两种。你一直对结论避而不谈。你敢不敢承认Lisp的函数实际上是有不同类型的？？？我举的不是你后来那个例子，我说的就是C++那个例子，如果*和/你根本就得不到其绑定的lambda对应的lisp代码，请问你怎么分析(lambda (a b)里面的a和b？你别咬住“函数体”三个字就不放行不？你也承认了*和/再展开就是C代码了，那么*和/和普通函数是不是一样？如果是一样为什么会有这样的区别？如果不是一样那你为什么不说Lisp有四种基本的form？

我的核心思想是：你不能因为一个form是C的还是lisp的就去区分它，无论这个form是special-form还是normal-form，Lisp美就美在它概念统一（程序==数据，万物皆表），你这样完全是背离Lisp精神的，你是被埋在肮脏的shit里面然后以为Lisp的shit也是香的。
starwing83 发表于 2011-08-19 18:15

你的核心思想根本就是对我的误读。
我一直在从使用方式上区分两者：
1. 比如可以macroexpand
2. 比如是语言必不可少的元素， 缺少了就无法编程 —— 只是它们又恰好不是由lisp实现而已。

我说normal-form时， 有将 + * 单独提出来说吗？
sw君， 你还没明白吗？  如果要将 + * 单独提出来算作一种， 那才真是从实现方式来区分它们了。

所以我才说你一直在让我背黑锅， 从实现方式进行区别是你而非我一直在做的事情。

starwing83

回复 190# OwnWaterloo


    我仔细地审核一下你的需求：首先这是一个Lisp（确切地说，是ELisp的）的shit：lambda不被编译，你想填补这个shit，但是你忘了一个定理：当去掩盖而不是弥补一个shit时，这件事本身就是一个shit行为。

人身攻击完毕，我们来看你的填补结果。

首先，宏会产生一个一系列表，这些表是作为程序嵌入到待编译的 程序里去的。你并没有办法判断这些表是作为数据还是作为代码——还是两者都是，这是Lisp（而不仅仅是ELisp）的问题之一——正如同前面某人说过的，Lisp试图将复杂性推给程序员。是的，它帮你做了词法分析（简单地不能再简单的），给你了数据结构，可是——语法分析怎么办……你没有一个优雅地方法去判断一个form到底是数据还是代码，在你的例子里面，你没有办法去区分你想去处理的东西——这又是Lisp的一个shit：Lisp试图掩盖代码和数据的不同，然而代码和数据很多时候的确是不同的，比如说它们需要不同的操作（数据需要压缩，而代码需要被编译），这时你就shit了。现在的问题是，你得去做语法分析了。

但是，你选择了一个简单的方法，你不去做语法分析，而是判断某个特定的pattern——请问，你这么做和直接用正则表达式处理源代码有什么不同呢？难道仅仅是因为给你的是数据结构而不是文本你就觉得心理上有安慰感么？你以为数据结构就一定能执行？找不到函数神马的难道不会蹦么？这就是所谓Lisp的优势所在？这种类似正则的分析中，Lisp所谓的“优雅地”到底在哪儿？？

你这个方法还有缺陷，你并不真的知道人家传的到底是函数还是数据，所以你一笔带过“不可能做到完全的向后兼容的”，这根本就不是向后兼容！！这是Bug！是漏洞，是某种你完全不可能考虑到的泥沼，而你却为这种泥沼的制造者：ELisp辩护？

正如我所说的，Scheme没有这种问题，首先Scheme只有一个cell，所有的代码是明确的，所以根本不需要你去添加语义用于编译：eval会去分析并做你现在在做还做得很失败的事情。另外，Scheme是模式匹配的宏，也就意味着，将lambda添加function在Scheme里是个很简单的活儿，原理很简单：只有被执行的代码（即第一个项是个keyword）才会有宏展开，因此只有一个函数真的（打算）被执行，它才会被展开成(function (lambda的形式。这不优美么？

真的觉得你需要认真想想了。你在拿Lisp（确切地说是ELisp）的缺陷去赞美Lisp？你在用ELisp随心所欲的创始人的拍脑子想法去否定Scheme作为一门通用语言深思熟虑的特性？还美其名曰“Scheme的思想不是Lisp的思想”？你真的用过除了ELisp这种编辑器的副产品以外的Lisp吗？你觉得自己真的看到了Lisp全部的美，理解到Lisp全部的美，有资格去说这样的话，做这样的事情吗？

starwing83

回复 192# captivated


    胜负还未分晓，你怎么就说这么有失公允的话呢？

OwnWaterloo

回复  OwnWaterloo
    你可以说明这两种form不一样，正如同+和add不一样，但是这不能说明Lisp对这两种不一样的form的求值策略不一样，正如就算+和add不一样，你也不能说明Lisp对这两种不一样的函数的求值策略不一样。这才是我们讨论的东西。
starwing83 发表于 2011-08-19 18:40

我已经有点被绕晕了， 这里的两种form是 speical-form 与 macro 吧？

1. 你就只关注参数而非整个form的求值策略？ 这样真的可以吗？
2. 整个form的求值不同我已经说了： macro 可以被 macroexpand， speical-form 可以吗？
3. 即使是参数求值上的区别， 我也说了： macro 肯定都不求值， 而special-form 不这么解释也是可以自圆其说的。

starwing83

回复 193# OwnWaterloo


    好，我们认为shit就是个悲观和乐观的问题可以吗？我觉得Lua比别的其他的什么好有问题吗？


继续说，我的思想不是对你的误读，我的思想就是我的思想。我的命题是这样的：

Lisp的执行有且只有两个不同的分支：special-form和normal-form，其中special-form对其所有的参数不求值，而直接传递给函数，而normal-form对其所有参数求值再调用。

就这么简单，期间没有什么东西叫做macro的。macro+special-cons == special-form。

我已经说了近三遍了，你都没有回应，是故意的么？宏能不能被展开，和它调用时参数怎么被求值，一点关系都没有！！！


是不是语言必不可少的部分？貌似是你新提到的观点呢？找不到论据了么？可是我想再问问。是不是语言必不可少的部分，和他调用的时候参数怎么求值，有必然联系么？？？


说白了，我现在就是对Lisp做着你最讨厌的二元论：“Lisp只有两种调用方式，要么对参数求值，要么不求值”，这才是我的命题，你到底在反驳什么呢？

pandaiam

你们怎么可以这样吵起来。。。

starwing83

回复 196# OwnWaterloo


    很好，我觉得我抓到你的思想和我们的必然分歧了。

——原来，你的意思是，macroexpand这个操作本身，也是调用的一部分！

是这个意思吧？

3我们放着等会儿说，我们先解决这里的分歧（其实3我已经说过了，发明这种概念是无用的，将special-form和macro归并会更简单）。


我们说一下我对Lisp调用的步骤：
1. 读取表的第一项，在求值或者不求值（这里是实现定义，Scheme求值而Elisp不求值）后，查证符号表，寻找对应的操作以及类型。
2. 操作分为两种，special-form和normal-form，如果是normal-form，则对后面所有的表，按照刚才所说的方式求值（即本过程），然后待用。
3. 如果是special-form，直接将cdr(list)（即表从第二项开始的部分）交给对应操作。Over
4. 如果是normal-form，将计算后的结果交给对应操作。Over

这里注意了，如果是special-form，那么对应的操作是什么呢？答案是：对于macro，是macroexpand，对于狭义special-form，是交给下层直接处理（比如C代码）。
如果是normal-form，实际上对于操作也是两种：对于函数，执行函数的字节码，对于原始函数，直接将结果表给（比如）C代码让其执行。

看到了吗？单论调用步骤，一个form是specia-form还是macro是无所谓的。因为macroexpand操作和交给下层直接处理操作是平级的！

当然macroexpand操作之后还需要一些工作，比如将代码插入待分析序列，继续按照刚才的流程分析等等。但这些事情，都是属于“对macro本身的操作的附加动作”，而不是一些额外的，可以在调用过程中将macro和狭义special-form分开的事情！！

进一步说，其实“对参数进行求值（即第二步）”也可以看做是对函数这种类型本身的特殊操作！在这个意义上，其实可以看做对所有的form，都是不计算参数的！而是根据不同的类型，去做适当地操作！这种方式实际上更加泛型。

这就是我的意思。

OwnWaterloo

回复  OwnWaterloo
我已经说了近三遍了，你都没有回应，是故意的么？宏能不能被展开，和它调用时参数怎么被求值，一点关系都没有！！！
是不是语言必不可少的部分？貌似是你新提到的观点呢？找不到论据了么？可是我想再问问。是不是语言必不可少的部分，和他调用的时候参数怎么求值，有必然联系么？？？
starwing83 发表于 2011-08-19 19:04

哥哥， 还这么大的字， 吓死人了。
我不是没有回应， 也不是找不到论据， 而是在196才发现你居然犯有这样一个我想都没敢想的错误。

1. 你就只关注参数而非整个form的求值策略？ 这样真的可以吗？
OwnWaterloo 发表于 2011-08-19 18:59

这也太初级了吧……

PS： "语言必不可少部分"不是新观点， 而是争论一开始那个帖就提出了，  153楼， 第3条。


既然这样， 我这里也有几个一直没得到解答的问题， 还请一一赐教啊：

1.

回复  starwing83
我没兴趣与你纠缠这些概念， 你只回答我一个问题就好了：
common lisp里能将 (if c x y) 展开吗， 能将 (push l x) 展开吗？
当别人问起为什么前者不能而后者能时， 你该如何作答？
OwnWaterloo 发表于 2011-08-19 16:59

2.

我说的是正统的Scheme没有macro-expand，但是几乎所有的发布版都带了这个标准外的函数，目的也无非就是调试，所以这一点Scheme并不差。但是，Scheme绝对不鼓励改变宏运行后产生的代码这种危险的行为。这种行为本身就和你得到一个指向未知对象的指针然后以为第四个字节的偏移位置就是长度然后瞎改一样危险。
starwing83 发表于 2011-08-19 17:51

不是肮脏吗？ 为什么又要带？
上面也说了， 那些看上去危险的动作不一定就是错误。

同时 —— 既然带了这个标准外的函数 —— 那么它可以展开哪些？ 又不能展开哪些？ 如何解释其中的不同？
OwnWaterloo 发表于 2011-08-19 18:39

先就这两个吧……  周末了， 网速更不给力了……