学习Haskell中...
limkatkat
是在想把一个列表的值分别打印到一个新行中
但是下面这个do却死活通不过。
这到底是咋回事啊？
晕乎乎。。。
printStr arr = do
if arr /= []
then do putStrLn show(head(arr))
printStr tail(arr)
else do putStrLn "No more Items..."
提示这个：
Main.hs:22:19:
Couldn't match expected type `String'
against inferred type `a -> String'
In the first argument of `putStrLn', namely `show'
In the expression: putStrLn show (head (arr))
In a stmt of a 'do' expression: putStrLn show (head (arr))
Failed, modules loaded: none.
katkat lim
Jay True
katkat lim
Jay True
所以，其实这行可以写成：putStrLn $ show $ head arr ，一个括号也没有。
Wei Hu
On Oct 17, 9:19 am, "Jay True" <glac...@gmail.com> wrote:
> 嗯，这两种写法是等价的，而 $ 就是为了减少括号的数量而设计的。
>
> 所以，其实这行可以写成：putStrLn $ show $ head arr ，一个括号也没有。
>
>
>
> > 不用加，换成putStrLn (show(head arr ))
>
>
> > 中间加个 $ 号哈
>
> >> 2008/10/17 katkat lim <limkat...@gmail.com>
>
> >>> 晕，看到后面的时候突然明白了。。。原来是超低级错误。。。
>
> >>> 2008/10/17 limkatkat <limkat...@gmail.com>
Jay True
katkat lim
fisher
Yufei Chen
SICP 对面向对象和函数式程序的模块性有过一段评述。见 3.5.5 Modularity of Functional Programs
and Modularity of Objects
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-24.html#%_sec_3.5.5
脚注 76 对面向对象什么时候适用什么时候不适用的评述值得注意。
我自己的一点看法。
现实世界的对象用面向对象的方式来描述是更加容易，但并不一定是对对象的描述越直接就越好，有时候甚至是用直观的方式很难对问题进行描述。就像数学对问题的抽象有时候并不是那么直观，但在完成这一步抽象之后却能够使得问题得到简单的解决，或者是一个方法能够适用于很多的问题。
当然，当对问题的描述方式不是那么直观时，完成这一步抽象的困难也是必须要克服的。
因此无论是面向对象还是函数式的思维方式都有其优势和不足之处，然而结合这两者优点的思维方式还没有出现。
2008/10/18 fisher <wangq...@gmail.com>:
> 个人觉得 函数式编程 不太符合人的 思维方式，比较难掌握。 有种想法：会不会有一天 可以将 用面向对象思维 编写的程序 由 某种方式 转化成 由函数式
> 表示的 代码，再利用其 良好的 原子性 和 并发性。
>
--
Best regards,
Chen Yufei
katkat lim
fisher
我个问题，一直不明白 ， 很想请教你一下：
从一篇文章里面 摘抄的 函数式 语言 的优点 体现在 ：
函数式程序不包含任何赋值语句，因此变量一旦被赋予一个值，就不再改变。更一般地说，函数式程序不包含任何副作用：除非对函数进行求值，它不会有任何效 果。这一特性消灭了错误的一个主要来源，同时也使执行顺序不再重要——因为没有副作用能够改变表达式的值，因此可以在任何时刻对它求值。
这里说了 函数式编程 的输入是 自变量 ，中间过程 已经 在编写 的时候就确定，因此结果 也是确定的，没有中间 任何副作用。
那么 如下的 一个函数 是否 无差错的 可以完成上述 的任务？
我定义一个 结构化的 函数
int volatile f (int x)
{
do something
return ?;
fisher
Jay True
总的来说，函数式语言区别于命令式语言的最大一点其实是，将函数作为语言中的一等公民来对待，以及通过函数的组合使用来达到求解问题的目的。
至于陈宇飞所提到的将用面向对象思维所写的程序转化成函数式的代码，我觉得没有必要，更现实一些的作法是两者的结合。当然，我说更现实，是因为已经有了这样的实例，比如 scala 以及 ocaml 。而且在我看来，这两者并不是可以相互取代的存在，而是互补的存在。
所以，对于对函数式语言感兴趣的程序员，完全可以从 scala 和 ocaml 这类语言入手，并且这种语言也许会有更好的发展前景。
Yufei Chen
不太明白你的意思，用函数式替代了什么？
2008/10/18 Jay True <gla...@gmail.com>:
> 嗯，你提到的函数式语言的优点，其实指的是纯函数式语言的优点，比如 haskell 。除此之外，还有别的种类的函数式语言，比如大家都知道的 lisp
> ，还有 OCaml 等，在这些函数式语言中，就有对变量的赋值，以及非惰性求值。
但要惰性求值基本上一定得是纯的才行，函数式语言没有惰性求值就不那么漂亮了。
>
> 总的来说，函数式语言区别于命令式语言的最大一点其实是，将函数作为语言中的一等公民来对待，以及通过函数的组合使用来达到求解问题的目的。
>
> 至于陈宇飞所提到的将用面向对象思维所写的程序转化成函数式的代码，我觉得没有必要，更现实一些的作法是两者的结合。当然，我说更现实，是因为已经有了这样的实例，比如
这个不是我的观点，明知道我对面向对象不感冒的。我说的是结合两种思考方式优点的方式还没有出现。
> scala 以及 ocaml 。而且在我看来，这两者并不是可以相互取代的存在，而是互补的存在。
>
> 所以，对于对函数式语言感兴趣的程序员，完全可以从 scala 和 ocaml 这类语言入手，并且这种语言也许会有更好的发展前景。
前景的话 Haskell 确实不会比 scala/clojure/ocaml 好。
>
> 2008/10/18 fisher <wangq...@gmail.com>
>>
>> 如果简单的替代的话，为何 要费很大的劳神 ，用函数式？
>
>
--
Best regards,
Chen Yufei
Wei Hu
On Oct 18, 9:21 am, fisher <wangqi1...@gmail.com> wrote:
> 如果简单的替代的话，为何 要费很大的劳神 ，用函数式？
fisher
1, 函数本身 是 volatile 的，而且 函数 入口 和出口 进行EnterCriticalSection ， LeaveCritical Section 。
2, 函数 只对 输入 的参数 和 输出 影响，不对 任何 外围的 变量 进行操作。
这样写出来的函数 还有 副作用么？
Jay True
Wei Hu
就算你说的那个函数是pure的，你无法保证所有函数都是pure的。Haskell从语言一级就保证了这一点。
On Oct 18, 9:46 pm, fisher <wangqi1...@gmail.com> wrote:
> 为何无法保证 没有副作用 ，还有 您指的 副作用是什么，假设我有以下对 c 函数的约定，能否避免您所指的副作用：
>
> 1, 函数本身 是 volatile 的，而且 函数 入口 和出口 进行EnterCriticalSection ， LeaveCritical
> Section 。
> 2, 函数 只对 输入 的参数 和 输出 影响，不对 任何 外围的 变量 进行操作。
>
> 这样写出来的函数 还有 副作用么？
>
fisher
fisher
Wei Hu
函数式编程只是一个思维习惯的问题，而你坚持用C来进行low-level的程序设计，面临的是一个爆炸的状态空间，人脑是不适合干这事的，必须将问题
抽象，在高层解决。
在这个帖子继续下去，也只是空谈，你应该找一门语言来学习。
On Oct 18, 11:27 pm, fisher <wangqi1...@gmail.com> wrote:
> 如果设计一个复杂的程序，就像 C 的设计者 要考虑考虑内存模型、和多线程，带来一些思维负担（这有现成的解决方法）， 而函数式编程 将要考虑如何用
> 并不直观的的思维 方式 进行建模与实现，这也许将带来更大的思维负担。反倒不利于设计。
>
Jan
> 如果设计一个复杂的程序，就像 C 的设计者 要考虑考虑内存模型、和多线程，带来一些思维负担（这有现成的解决方法）， 而函数式编程 将要考虑如何用
> 并不直观的的思维 方式 进行建模与实现，这也许将带来更大的思维负担。反倒不利于设计。
建模不会有太大区别，用fp也很容易写出OO的代码。而到了实现的时候，我想还是imperative
style会带来更大的思维负担: 它迫使程序员考虑howto,在一个比较低的层面上思考问题，而不是whatto.
参考Backus的turing lecture <<Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs>>, 很明确的指出了imperative style对思考方式的限制。
Thanks,
Jan
>
>
>
> 2008/10/19 Wei Hu <wei...@gmail.com>
>
> > 1. 你需要考虑内存模型、和多线程，这本身就不pure了。
> > 就算你说的那个函数是pure的，你无法保证所有函数都是pure的。Haskell从语言一级就保证了这一点。
> >
> >
--
jan=callcc{|jan|jan};jan.call(jan)
Wei Hu
On Oct 18, 11:47 pm, fisher <wangqi1...@gmail.com> wrote:
> *而函数式编程 将要考虑如何用 并不直观的的思维 方式 进行建模与实现，这也许**将带来更大的思维负担。*
fisher
Wei Hu
On Oct 18, 11:57 pm, fisher <wangqi1...@gmail.com> wrote:
> 如果所要问题的规模不变，那么所需处理的状态不会因为 用什么语言而带来减少。总是去想what to do ,最终也要 有 howto
> 实现才行，回避不了的。
>
>
>
> > 建模不会有太大区别，用fp也很容易写出OO的代码。而到了实现的时候，我想还是imperative
> > style会带来更大的思维负担: 它迫使程序员考虑howto,在一个比较低的层面上思考问题，而不是whatto.
>
> > 参考Backus的turing lecture <<Can Programming Be Liberated from the von Neumann
> > Style? A Functional Style and Its Algebra of Programs>>, 很明确的指出了imperative
> > style对思考方式的限制。
>
> > Thanks,
> > Jan
>
fisher
Yufei Chen
人们使用一门语言的时候倾向于使用它支持的最自然的编程方式，因此习惯于一门有足够抽象能力的语言的程序员倾向于不去学习新的语言，因为他们觉得没有必要。如果有这样的倾向就意为着你的思考方式可能被语言所影响了。
我不否定其他编程方式，但是局限于一种风格限制的是自己的视野。编程风格很多，其中函数式风格值得一学。而学习函数式风格最好的办法还是学习一门函数式的语言。
所有编程语言都是图灵等价的，但是我们还是在不停的发明新的语言来解决问题，原因在于不同的语言抽象能力不同，对问题的描述方式也不同。
类似的，用 C 也可以写出面向对象或者函数式风格的代码，但我们仍然创造出专门的面向对象语言和函数式语言，原因在于不同的语言本身适合的思考方式不同。很显然
，用 C 写面向对象或者函数式的代码不会那么令人愉快。（创造出这些新语言的人的 C 语言的功力肯定不在我们之下，如果他们觉得用 C
也能方便的写出其他风格的代码也不会自找麻烦弄新的语言出来，即使弄出来了也不会有这么多人去用。）
一门语言支持那种特定的编程方式很大程度上由其语法决定，好的语法可以使得代码更简洁，可读性更好，因而维护起来更简单。我在学习 Haskell
之后自觉的在 Python 代码大量使用 map/filter/partial/compose 等函数，这些函数很多情况下比嵌套使用 for
循环更加方便而不易出错（前提是习惯以后），但是 Python 没有对 partial/compose 这样的操作在语法上进行支持使我觉得在
Python 中写函数式的代码不那么愉快，不仅要多打字，可读性也比 Haskell 的代码差。（可想而知在 C 中写这样的代码会有多痛苦。）
语言还可以防止程序员犯错，就像静态类型，就像 GC，就像 Java 限制程序员使用指针。（Java
的例子并不太好，好的程序设计语言应该在避免犯错的同时不限制程序员能够做的事情。）纯的函数式语言确实是对程序员加了不少限制，有些限制可以减少错误的发生，而在这些限制的上也得到了其他的东西，比如惰性求值。
关于语言方面更多的思考推荐你看看 Paul Graham 的不少文章，我的很多想法是受他的文章的影响。关于编程的本质推荐看
SICP。还有另外一本书，Concepts Techniques and Models of Computer
Programming，或许比 SICP 更具体更容易些，用一门支持多种编程范式的语言 Oz
为例，介绍了各种编程范式，我只看过目录，很多人也推荐这本书。
其实不止是函数式，并发模型以及支持它的语言也值得学习。The Pragmatic Programmer 中推荐程序员每年学习一门新的语言是有道理的。
如果说这些还不够的话那再推荐你看看李笑来老师的文章，比如这篇
http://www.xiaolai.net/index.php/archives/687.html
有些事情有没有好处只有做了才知道，也有些事做了是肯定有好处的。做事太考虑结果或许会错过一些很好的机会。这个扯远了。
2008/10/19 fisher <wangq...@gmail.com>:
> 抱歉，没有， 没有理解它所带来的好处之前，没有去学习它的动力。或许您可以举一些例子让我们这些还有疑问的人理解。
>
--
Best regards,
Chen Yufei
Yufei Chen
> * fisher <wangq...@gmail.com> [2008-10-19 11:27:09 +0800]:
>
>> 如果设计一个复杂的程序，就像 C 的设计者 要考虑考虑内存模型、和多线程，带来一些思维负担（这有现成的解决方法）， 而函数式编程 将要考虑如何用
>> 并不直观的的思维 方式 进行建模与实现，这也许将带来更大的思维负担。反倒不利于设计。
>
> 建模不会有太大区别，用fp也很容易写出OO的代码。而到了实现的时候，我想还是imperative
> style会带来更大的思维负担: 它迫使程序员考虑howto,在一个比较低的层面上思考问题，而不是whatto.
>
> 参考Backus的turing lecture <<Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs>>, 很明确的指出了imperative style对思考方式的限制。
赞推荐！
Backus 发明了 Frotran，没弄错的话他后来却一直都是支持函数式编程的。
再次缅怀下大师级的人物。
>
> Thanks,
> Jan
>
>>
>>
>>
>> 2008/10/19 Wei Hu <wei...@gmail.com>
>>
>> > 1. 你需要考虑内存模型、和多线程，这本身就不pure了。
>> > 就算你说的那个函数是pure的，你无法保证所有函数都是pure的。Haskell从语言一级就保证了这一点。
>> >
>> >
>
> --
> jan=callcc{|jan|jan};jan.call(jan)
>
--
Best regards,
Chen Yufei
Yufei Chen
> 而函数式编程 将要考虑如何用 并不直观的的思维 方式 进行建模与实现，这也许将带来更大的思维负担。
>
> 我之所以这么说 是因为 软件工程里 的 第一类问题是最难解决的（人月神话）
> 对现实世界、物件之间交互的建模， 是比较难的，也是最费功夫的，函数式 也许恰恰在多数情况下增加了这种难度， 而对于第二类问题，
再次重复之前说过的，对现实世界的直观描述并不一定导致最好的解决问题的办法。换个描述方式问题或许就明朗了。
换个描述本身并不难，难的是找到能简化问题解决的描述。有些时候 OO 的描述可以简化问题，有些时候函数式可以，有些时候可能是其他的描述方式。
把现实世界用函数式的风格进行描述不是太难，只是需要花时间习惯，就像学习 OO 一样。
> 目前的比较热门的程序设计语言 并没有什么太大的差别。
我不知道什么是第二类问题。冷门的程序设计语言或许就有大的差别。
如果你看过 Project Euler 上有人用 J 写的代码的话就会感叹语言的差别实在是太大了。
fisher
陈 你好：
感谢推荐了几本 好书。
函数式 思维方式 和 面向对象式 很不一样，对于拓展锻炼思维也许很有好处。我所质疑的是他实用性（程序员是否 容易 理解 接受 并最终应用， 它是否能方便的做出有用的产品）， 如果暂时不能，那仅仅是很酷的思维方式，恕我 孤陋寡闻 ， 我所看到的FP 例子 和 教程 仅仅是 纯粹的计算。
Jay True
终于，比较能掰活的人出来发话了，基本上属于正面的引导，我就来点反面的吧。
话说，如果你不自己去学习，去使用，去体会，而只想通过别人的介绍来了解某一样事物的话，又有多大的概率能体会到这个事物的好处呢。
想要一个学习的理由吗，了解使用它能带来的好处哈。
Jay True
Jay True
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
Yufei Chen
http://www.math.chalmers.se/~rjmh/Papers/whyfp.html
里面用的语言是 Miranda (不知道这个名字是不是来自作者 David Turner 的某女友或者女儿)。有人哟故 Haskell 写了另外的一个版本。
看过以后如果你赞叹文中程序本身的优雅的话就学学吧，如果觉得这些例子没什么实用价值的话就算了。
个人认为代码是有优雅和丑陋之分的，要是从来没有过这种感觉只在乎是否实用的话我没什么好说的了。
2008/10/19 Jay True <gla...@gmail.com>:
> 纯粹的计算吗，了解过 pugs 这个项目吗，没有的话可以去了解一下。
呵呵，真像是你的口气。
>
> 2008/10/19 fisher <wangq...@gmail.com>
>>
>> 陈 你好：
>> 感谢推荐了几本 好书。
>> 函数式 思维方式 和 面向对象式 很不一样，对于拓展锻炼思维也许很有好处。我所质疑的是他实用性（程序员是否 容易 理解 接受 并最终应用，
>> 它是否能方便的做出有用的产品）， 如果暂时不能，那仅仅是很酷的思维方式，恕我 孤陋寡闻 ， 我所看到的FP 例子 和 教程 仅仅是 纯粹的计算。
不是纯粹的计算，real world haskell 里面就有很多实际的例子。
不是不能，Haskell 的话 pugs, darcs 就是例子，Linspire 的包管理器是用 Haskell 写的。ITA 内部是用
Common Lisp 的。gnumeric 扩展是用 Scheme 的。mldonkey 是用 ocaml 的。
总的来说函数式语言的项目不多，实用还不够广泛，但语言的质量高低和流行度没有绝对的联系。
我自己也觉得 Haskell 不会被很多人接受，至少得改头换面成 F# 那种样子才可能成为 popular language。而且
Haskell 作为研究型的语言要 avoid success at all cost (Simon Peyton Jones
原话)，用户太多就不能方便的进行演化。好在现在的 Haskell
都是自愿选择这门语言，即使有变化大家也不会太抱怨，但其实它现在的流行程度到了已经有人开始抱怨 library 的变化导致的问题。
但即使在工作中没有直接使用 FP 语言的机会，但通过学习 FP
而开阔了视野这本身就已经值得了。你要那么在乎目的实用性自己一点时间都不投入的话就算了，多说也没用。
fisher
MLDonkey
100% Open Source, GPL licenseWritten in ObjectiveCaml, with some parts written in C and some in Assembly.
ObjectiveCaml (Ocaml for short) is a multiparadigm general purpose programming language : it is primarily an object oriented functional language, but it also allows to program in imperative style when needed.
fisher
如果 FP 的一个实现里面 支持了 IO， 那么 IO 操作一定带来 系统状态的影响，这和 FP 的初衷 "无副作用" 相悖。可以这样理解么？
Wei Hu
katkat lim
Jay True
总的来说，在 haskell 这个 no side effect 类型的 fp 语言中，对这个问题的解决方法是，pure 部分和 non-pure 部分的隔离，non-pure 部分，也就是处理 IO 的代码（当然不止于此），通过调用 pure 部分的代码来实现其功能，反之则不行。另外，就算是 non-pure 部分的代码，虽然其函数的实现大多使用了 monad 技术，看起来很 impretive ，但这只是一种语法糖，其实质仍然是函数式的编程方法（为追求效率的底层实现除外），仍然可以利用函数式方法强大的表现力。
另外，我们举的那么多例子都白举了吗，你一点都不想去了解，而只会在这里想象"基本上这个只能做计算"吗？并且，程序的核心难道不是计算吗？
以上。
katkat lim
fisher
让历史来说明吧。
Jan
天天用, hehe
* fisher <wangq...@gmail.com> [2008-10-19 13:26:12 +0800]:
--
jan=callcc{|jan|jan};jan.call(jan)
Jay True
up duan
fisher，我说一下：
你说：
>如果所要问题的规模不变，那么所需处理的状态不会因为 用什么语言而带来减少。总是去想what to do ,最终也要 有 howto 实现才行，回避不了的。
其实不是这样的。举个物理学中的例子，高中的时候经常会有这种题，让我们计算有好几个因素影响下的一个系统我们做了多少功之类的，如果采用F=Ma这个方式去算，可能维度很多，涉及到微积分之类的方式，可是如果用能量守恒定律的话，或许我们就可以简单的得出结果了，因为我们不再纠缠于细节，而是直接把握其实质。
或许这个例子不怎么恰当，但是我觉得它有点用。
函数式编程就是要我们不要去想如何去做，而是想规律是什么，也就是说，我们不需要给出步骤的描述，我们给出规则的描述。不给出动作，只给出关系。a = b + c在命令式语言中看做一个执行操作，一个动作，在函数式语言中看做一个规则，一个关系，一个永恒不变的东西。
Xie Hanjian
backus他老人家也仔仔细细的给分析了一遍 无奈别人不爱看 :-)
* up duan <fix...@gmail.com> [2008-10-19 22:17:46 +0800]:
Yufei Chen
fisher
to up duan：
函数式编程就是要我们不要去想如何去做，而是想规律是什么，也就是说，我们不需要给出步骤的描述，我们给出规则的描述。不给出动作，只给出关系。a = b + c在命令式语言中看做一个执行操作，一个动作，在函数式语言中看做一个规则，一个关系，一个永恒不变的东西。
to Others:
FP发展了 20多年， 也仅仅出现了 一些 应用 了 Non pure FP 的程序， 历史上也曾 出现过 lamda 机器，后来也无声无息消失了。
pure FP ， 从未来的发展看，他的长处 也仅仅 在并行计算中。（non pure FP部分）就不说了， 名字就已经很诡异了， 我觉得采用 （FP语言中 与指导思想相矛盾但又离不开的技术）比较本分一点。
up duan
忍不住想说你在"诡辩"：）。
或许你知道我在说什么而故意混淆，或许你由于世界观的缘故对我的看法根本看不入心，无论如何，你用动作+状态变化来概括你世界中的程序，并不能断定别人用关系和规则概括别人世界中的程序是错误的。
而你扯到不知所云的软件工程，更是拿出《人月神话》这个大棒槌来指责我，我觉得很是诡异。
我想Haskell应该是一个PureFP吧，Pugs不知道算不算是一个程序呢？
说实话：
> ……我觉得采用 （FP语言中 与指导思想相矛盾但又离不开的技术）比较本分一点。
这句话我确实没有理解：（。
fisher
3.2.4.1 Side effects in the language
Some functional languages extend their purely functional core with side effects. The programmer must make sure himself that he doesn't use impure functions in places where only pure functions are expected.
3.2.4.2 Side effects through monads
Another way of introducing side effects to a pure language is to simulate them using monads. While the language remains pure and referentially transparent, monads can provide implicit state by threading it inside them. The compiler does not even have to 'know' about the imperative features because the language itself remains pure, however usually the implementations do 'know' about them due to the efficiency reasons, for instance to provide O(1) mutable arrays.
Allowing side effects only through monads and keeping the language pure makes it possible to have lazy evaluation that does not conflict with the effects of impure code. Even though the expressions are evaluated lazily, some parts of them are forced by monads to be evaluated in a specific order and the effects are properly sequenced.
除非你的程序 不用 IO， 用了 IO ，FP 会进行两种方式的处理，第一种，干脆放弃pure 的方式，第二种 ，搞个第三者，把不是那么纯粹的东西 扔给他，有了问题也是他的问题（鄙视一下 ，haskell 官方网站老是说自己那么纯粹）。
目前的计算机的计算方式是 实现不了理论上 纯的 FP的。
我并没有 说 "别人用关系和规则概括别人世界中的程序是错误的"，请你仔细看我的留言，我只是说 软件工程主要矛盾是在 建模上，而 FP 并没有 提出很多 对现实世界工作建模的 模型，况且自身还存在很多 问题。
Jay True
说一个 FP pure 不 pure，意思是他有没有 side effect，而 side effect 是个什么东东呢？就是外部世界的状态变化，这个大家可以接受吧。
那么这个外部世界的状态变化在我们的程序中又可以怎样表示呢？在一个 imperative 语言中，类似这样：
printf ("Hello, world!\n");
这里，我们只是把"什么变化"告诉了世界，至于是哪个世界，以及之后世界会变成什么样子，不关我事。
而在一个 pure functional language 中，要怎么表示呢？这样：
newworld = print oldworld "Hello, world!\n"
这里，我们不止把"什么变化"传了进去，同时也把"执行这个函数之前的状态"传了进去，而这些就是要执行这个函数所需知道的全部信息了。而这个函数返回给我们的，就是作了改变之后的世界，而我们就可以对这个新世界做进一步的处理了。
实质上，在 haskell 中，那些看起来是 non pure 的部分，其本质仍然是 pure 的，只不过 haskell 定义了一些语法糖，把那一坨 old world 啊 new world 啊什么的隐藏起来了，省得你写起来烦不是？
对了对了，还有赋值，对于那些深受命令式语言毒害的同志们，我可以很负责任的告诉你们，这在像 haskell 这样的 pure functional language 里面也是完全可以办到的，理由参上。
那你会说了："既然我可以以命令式的方式来用 pure functional language ，我又何苦要用它呢？"是啊，您又何苦呢，没人让您以 imperative 的方式来用啊，您非要写 imperative 的程序，我不仅不阻止，而且会非常推荐您用 C family 或其他您喜爱的语言的，以免浪费您宝贵的时间，精力，以及 functional language 所提供的强大（至少在我看来）功能。
以上
Yufei Chen
经验，也不愿意花时间得到一点深入的了解，以结果来判定一样东西好坏的人浪费时间了。
2008/10/20 up duan <fix...@gmail.com>:
--
Best regards,
Chen Yufei
Cao Yi
Xie Hanjian
* Yufei Chen <cyfd...@gmail.com> [2008-10-20 07:48:23 +0000]:
--
jan=callcc{|jan|jan};jan.call(jan)
Jay True
你说 FP 并没有对真实世界建模的方法，那你想说的是不是 OO 才是更能对真实世界建模的方法呢，抱歉，我知识面很窄，据我所知道，大部分程序员都是这么认为的，那么，我想问，事实真的如此吗？
好吧，我承认，世界是由对象组成的，对象分属不同的类，每个类有不同的方法，而且类又可以属于不同的大类，甚至多个（多继承）。嗯，看起来，用面向对象的思想来描述这样的世界正合适，不是吗？
那么，我就要问了，方法是属于类的吗？或者更准确一点，一个方法一定是属于一个类的吗？
知道 multimethod 的同学们，请跳过下一小节。
那么，啊，很不幸的，一辆汽车撞上了一根电线杆，我们是应该调用汽车的碰撞函数，还是应该调用电线杆的碰撞函数呢？
其实我知道这个例子不恰当，因为你会说，碰撞这个函数属于物体这个类，而根据力的相互作用原理，谁撞撞还不是一样的？
是哈，如果仅从物理学的角度上来说，上述观点是完全成立的。但别忘了，我们是在现实世界，汽车撞坏了是要修的，电线杆撞坏了也是要修的，还有其他乱七八糟的事情，交通混乱啦，警察叔叔啦，。。。。
好吧好吧，我这就有点赖皮了，说回正题。汽车撞了，嗯，这和汽车与电线杆之间的相撞是一回事吗？是一回事？也就是说这次相撞是汽车的方法喽，当然啦，反正电线杆歪了又不关你什么事。
嗯，这个话题我们就讲到这里吧（讲不下去了）
对了，我想起来了，怎样建模跟用什么 style 的语言有什么关系？那不是类型系统的嘛。不要告诉我你认为类型系统与 style 是一回事。
而说到类型系统，你认为 haskell 的类型系统不足以描述现实世界吗？那看来你还需要接受扫盲。。。下次吧，如果你有兴趣的话。
以上
fisher
你说 FP 并没有对真实世界建模的方法
Jay True
这位兄台，如果只是学了 haskell 的语法的话，那就试试 Project Euler 吧，对数学知识的要求没那么高的，同时很适合练习 FP 的思想哈。
Jay True
up duan
我不知道Fisher为什么非要选择性失明。
Haskell是Pure的。而不是non Pure的。或许你觉得IO一定要用状态才能描述，可是哪只是你的世界观，Monad也可以描述的。
而Monad其实是Pure的。我想你应该先仔细看看它们怎么通过lamdba和high order模拟出你关注的state再考虑对Haskell纯与不纯做个判断吧。
fisher
这是从 haskell 官网上摘抄下来的，如果这句话还要我翻译，那就不用再说了，呵呵。这样做 无非是保持haskell 自身的冰清玉洁， 而把 一门实用的编程语言必须面对的东西交给了其他东西。
如果 有人不理解 IO 会产生什么样的 Side effect , 那也许不会理解，FP 要假借 Monads。
Jay True
嗯，其实是四个，不过根据 haskell 的类型系统，只要实现了其中两个，编译器可以为你推出另外两个。
重点是，这两个函数是纯函数！！！
至于怎么办到的，鬼知道你想不想知道。
Jay True
话说程序的执行，其本质是什么嗫，在我看来，就是状态的迁移啊，状态的迁移是什么嗫，就是一个东西，从一个状态变到另一个状态啊（这不费话嘛）
那么，在 imperative 中是如何表示这个状态的迁移嗫，赋值啰，这个大家都能接受吧（IO？不也是赋值嘛，只不过赋到那里你不知道罢了）
那么，在 functional 中是如何表示呢？new_state = func old_state 啰（IO？也在 old_state 和 new_state 中。什么样子？问 SPJ 去）。注意，等号不是赋值哈，是绑定，或者叫替换。那又有一个改变呢？new_state2 = func new_state 啰。那有很多改变的话，岂不是要很多变量？有语法糖啰。是什么样子的呢？我不告诉你。
以上。
PS 针对某些同学死抓着官网上对 haskell non pure 的说法不放，我在此澄清，不，是承认，IO 的底层实现确实是 non pure 的，谁叫现在老冯的机器称王称霸呢。不过，既然语言为我们提供了一个 pure functional 的接口，你非要管它底层是怎么实现的做什，这样可是很不工程的哈。
另外，关于 pure 的代码不能调用 non pure 代码的问题，这不是很明显吗？既然你是 pure 的函数，那就说明你的工作就是把输入映射到输出，对吧？我没给你外部世界的状态，你又怎么能支改变他呢？
以上 again 。
fisher
"pure FP ， 从未来的发展看，他的长处 也仅仅 在并行计算中。（non pure FP部分）就不说了， 名字就已经很诡异了， 我觉得采用 （FP语言中 与指导思想相矛盾但又离不开的技术）比较本分一点。。"
pure FP 本身是建立在 严密的数学 推理上的， 但是 他所依赖的基石 却又是那么充满未知性。
SpitFire
--
SpitFire
Jay True
Yufei Chen
Yufei Chen
看来你来兴致了。很好，加油，我看好你哦！
2008/10/20 Jay True <gla...@gmail.com>:
看来你没写过 FP 的代码但对其基石有所了解啊？原来是学院派的。愿闻其详，再解释下为啥是充满未知性的吧。
Jay True
话说 lambda calculaus 是跟图灵机等价还是跟冯氏图灵等价来着。貌似是前者，但不管怎样，这个基石很"充满未知性"吗？我怎么不知道？现代计算机的理论基石是图灵机吧，那图灵机是不是"充满未知性"的呢？
再有，这个理论基础跟 FP pure 不 pure 没什么关系吧，只要是 FP 都是建立在 lambda calculus 的基础上的吧。
haskell 的另一个理论基础，我知道的就是 category 什么的了，可那也跟 pure 不 pure 没关系啊，那个是 haskell 类型系统的基础。
@fisher
你再拿 pure 不实用来说事我可跟你急哈，话说我已经跟你说过 N 多遍就算是 side effect 也可以通过 pure 的方式来实现啊。
Yufei Chen
> 靠，鄙视我，我本来就很幽默的好不好。
嗯，是本来就很好，不过很少展示忽略掉了。
>
> 话说 lambda calculaus
> 是跟图灵机等价还是跟冯氏图灵等价来着。貌似是前者，但不管怎样，这个基石很"充满未知性"吗？我怎么不知道？现代计算机的理论基石是图灵机吧，那图灵机是不是"充满未知性"的呢？
>
> 再有，这个理论基础跟 FP pure 不 pure 没什么关系吧，只要是 FP 都是建立在 lambda calculus 的基础上的吧。
>
> haskell 的另一个理论基础，我知道的就是 category 什么的了，可那也跟 pure 不 pure 没关系啊，那个是 haskell
> 类型系统的基础。
http://en.wikibooks.org/wiki/Haskell/Category_theory
>
> @fisher
>
> 你再拿 pure 不实用来说事我可跟你急哈，话说我已经跟你说过 N 多遍就算是 side effect 也可以通过 pure 的方式来实现啊。
可以看到 Haskell 的接受率肯定不会高的，好在这样它就可以不断演化了。不过还是赞你如此的努力。
Jay True
2008/10/20 Jay True <gla...@gmail.com>:> 靠，鄙视我，我本来就很幽默的好不好。
嗯，是本来就很好，不过很少展示忽略掉了。
>category theory，以前看到说是群论的一个分支。你也看过下面这篇文章吧
> 话说 lambda calculaus
> 是跟图灵机等价还是跟冯氏图灵等价来着。貌似是前者，但不管怎样，这个基石很"充满未知性"吗？我怎么不知道？现代计算机的理论基石是图灵机吧，那图灵机是不是"充满未知性"的呢？
>
> 再有，这个理论基础跟 FP pure 不 pure 没什么关系吧，只要是 FP 都是建立在 lambda calculus 的基础上的吧。
>
> haskell 的另一个理论基础，我知道的就是 category 什么的了，可那也跟 pure 不 pure 没关系啊，那个是 haskell
> 类型系统的基础。
http://en.wikibooks.org/wiki/Haskell/Category_theory
>可以看到 Haskell 的接受率肯定不会高的，好在这样它就可以不断演化了。不过还是赞你如此的努力。
> @fisher
>
> 你再拿 pure 不实用来说事我可跟你急哈，话说我已经跟你说过 N 多遍就算是 side effect 也可以通过 pure 的方式来实现啊。
同时，嗯，今天下午公司刚好没事，我很无聊，就来扮扮传教士。哼哼
fisher
Yufei Chen
wikipedia 上只提到 Haskell 的类型推断系统是 Hindley-Milner
的一个版本（这个我不懂，记得你看过类型系统方面的书，应该比我清楚），但是没有提它本身的类型系统是不是基于 category theory。
2008/10/20 Jay True <gla...@gmail.com>:
Wei Hu
monad、functor之类的理论基础，和类型的关系倒不大。
On Oct 20, 7:54 am, "Yufei Chen" <cyfde...@gmail.com> wrote:
> 那篇文章也没有这么明显的说，我只能 90% 的确定，所以想问你。
>
> wikipedia 上只提到 Haskell 的类型推断系统是 Hindley-Milner
> 的一个版本（这个我不懂，记得你看过类型系统方面的书，应该比我清楚），但是没有提它本身的类型系统是不是基于 category theory。
>
>
>
>
>
>
>
>
> > 2008/10/20 Yufei Chen <cyfde...@gmail.com>
>
> >> 2008/10/20 Jay True <glac...@gmail.com>:
> >> 嗯，是本来就很好，不过很少展示忽略掉了。
>
> >> > 话说 lambda calculaus
>
> >> > 是跟图灵机等价还是跟冯氏图灵等价来着。貌似是前者，但不管怎样，这个基石很"充满未知性"吗？我怎么不知道？现代计算机的理论基石是图灵机吧，那图灵机是不是"充满未知性"的呢？
>
> >> > 再有，这个理论基础跟 FP pure 不 pure 没什么关系吧，只要是 FP 都是建立在 lambda calculus 的基础上的吧。
>
> >> > haskell 的另一个理论基础，我知道的就是 category 什么的了，可那也跟 pure 不 pure 没关系啊，那个是 haskell
> >> > 类型系统的基础。
> >> category theory，以前看到说是群论的一个分支。你也看过下面这篇文章吧
>
> >>http://en.wikibooks.org/wiki/Haskell/Category_theory
>
> > 可以很负责任的告诉你，我没有看过，我只听说过这个名词，至于它跟类型系统有关，这不是你跟我说的嘛。
>
> >> > @fisher
>
> >> > 你再拿 pure 不实用来说事我可跟你急哈，话说我已经跟你说过 N 多遍就算是 side effect 也可以通过 pure 的方式来实现啊。
> >> 可以看到 Haskell 的接受率肯定不会高的，好在这样它就可以不断演化了。不过还是赞你如此的努力。
>
> > 呵，我没指望 haskell 的接受率能提高多少哈，我只是想多拉两个以后可以解我惑的人。
> > 同时，嗯，今天下午公司刚好没事，我很无聊，就来扮扮传教士。哼哼
>
>
> >> >> Jay 同学现在变幽默了嘛，我看你两个帖子都笑出声了 ^_^
>
> >> >> 2008/10/20 Jay True <glac...@gmail.com>:
> >> >> > 的方式解决的？你怎么可以跷课呢，这样是对老师的不尊重，同学。
>
Wei Hu
On Oct 20, 7:29 am, fisher <wangqi1...@gmail.com> wrote:
> *话说我已经跟你说过 N 多遍就算是 side effect 也可以通过 pure 的方式来实现啊。*
> **
> pure 在语言级别就屏蔽掉，要搞两套，如果可能做到，他会不去做？
>
> FP 计算 所依赖状态变迁时的确定性， 进行IO 有可能改变 理论上认为不变的东西。代码之美 上就有这样的说明。这个时候 也就是
> 理论的基础 不是那么可靠。
> **
Jay True
不跟你扯了，我晕了。
to others:
Haskell 的粉丝们，有什么有关 haskell 技术方面的问题欢迎找我交流哈。
to pongba:
这边连广告都有，大大不介意我们在这里讨论 haskell 吧，毕竟 haskell 就是我心目中的 Top Language 哈。
Yufei Chen
那篇讲 category theory 的文章在谈 functor 和 monad 之前把 haskell 中的类型作为 category
的 object，而函数作为 morphism，而 haskell 语言级别上还有 composition 的记号，所以感觉至少
haskell 的类型"标注"方式基于 category theory。
之前我凭感觉得到的说法一直没有找到官方的说法，原来就是错的……
2008/10/20 Wei Hu <wei...@gmail.com>:
> type theory 和 category theory基本上还是正交的，我觉得后者更难理解一些。category theory主要是作为
> monad、functor之类的理论基础，和类型的关系倒不大。
>
> On Oct 20, 7:54 am, "Yufei Chen" <cyfde...@gmail.com> wrote:
>> 那篇文章也没有这么明显的说，我只能 90% 的确定，所以想问你。
>>
>> wikipedia 上只提到 Haskell 的类型推断系统是 Hindley-Milner
>> 的一个版本（这个我不懂，记得你看过类型系统方面的书，应该比我清楚），但是没有提它本身的类型系统是不是基于 category theory。
>>
>> 2008/10/20 Jay True <glac...@gmail.com>:
>>
Wei Hu
On Oct 20, 9:57 pm, "Yufei Chen" <cyfde...@gmail.com> wrote:
> 嗯，有时间再看看什么是 type theory。
>
> 那篇讲 category theory 的文章在谈 functor 和 monad 之前把 haskell 中的类型作为 category
> 的 object，而函数作为 morphism，而 haskell 语言级别上还有 composition 的记号，所以感觉至少
> haskell 的类型"标注"方式基于 category theory。
>
>
> 2008/10/20 Wei Hu <wei....@gmail.com>:
Yufei Chen
fisher
看看老外在去年争论了什么。 我们不要在这里浪费时间在争论一遍 很多人讨论过的事情。
WUWEI:
没有学过 Monad ,并不代表我不能从 haskell 官方的发言中知道关于他的一些事情。难道将军要知道火箭是如何发射的才能去打仗，作决策？
我想写作 haskell wiki 的人至少不比你了解 Monad 少。
Wei Hu
Yufei Chen
首先它的目的是研究性的，而你的目的看来是实用巨多，虽然 Haskell 也能写出实用的东西，但它肯定不适合你。你不会喜欢 category
theory, type theory, monad, monad transformer, type inference, STM
等等一系列东西的，所以你不合适。
其次，你是要当将军的人，而我们是喜欢写优雅代码的人。大家站的层面不同，考虑问题的方式不同，谈不来的。
嗯，我们说了那么多最终被你证明是在浪费时间而已，所以算了。
2008/10/21 fisher <wangq...@gmail.com>:
--
Best regards,
Chen Yufei
Wei Hu
On Oct 20, 10:18 pm, "Yufei Chen" <cyfde...@gmail.com> wrote:
> 你可以选择不学 Haskell。
>
> 首先它的目的是研究性的，而你的目的看来是实用巨多，虽然 Haskell 也能写出实用的东西，但它肯定不适合你。你不会喜欢 category
> theory, type theory, monad, monad transformer, type inference, STM
> 等等一系列东西的，所以你不合适。
>
> 其次，你是要当将军的人，而我们是喜欢写优雅代码的人。大家站的层面不同，考虑问题的方式不同，谈不来的。
>
> 嗯，我们说了那么多最终被你证明是在浪费时间而已，所以算了。
>
fisher
如果你自认为 学过 haskell ，连他官方的观点都不去看，那我认为你自认为的research 一定会走很多弯路。
haskell 发展了 20多年，到现在有多少实际应用， 为何不去学习历史，应该认真分析下，问题在何处？
好了，我工作也挺忙，就像 陈 所说， 这是个人的爱好，尊重你们。不再聊了。
Wei Hu
的。
Wei Hu
"除非你的程序 不用 IO， 用了 IO ，FP 会进行两种方式的处理，第一种，干脆放弃pure 的方式，第二种 ，搞个第三者，把不是那么纯粹
的东西
扔给他，有了问题也是他的问题（鄙视一下 ，haskell 官方网站老是说自己那么纯粹）。
目前的计算机的计算方式是 实现不了理论上 纯的 FP的。 "
说明你根本没看懂。Jay True向你解释了，你或者是没有理解，或者是带有偏见而没有去理解。我也不可能再试着向你解释，毕竟说服一个固执的人对我
并没有什么好处。
up duan
根据Fisher的说法，总是让我想起以前有人说C不过还是汇编，就是加了语法糖而已，C++还是C，不过加了语法糖而已。呜呼……
根据anderson的说法，OO【单指实现啊】不过就是语法糖而已，为什么我们允许OO，而不允许lambda？【注：有人就lambda引入C#质疑anderson，说不过就是匿名委托而已云云】，提供lambda明显能让抽象【表达能力】提升一个层次，可是就是有人忽略这一点。
如果关注经济利益，就应该看到Haskell提供一个PureFP带来的表达能力能够提升我们表达现实问题的能力，可以以更高的性价比提供软件，符合人类社会发展的方向：）。
当然，未来未必是Haskell的，也未必是PureFP的，但是，我们至少应该保持心态开放不是！