p*****2
发帖数: 21240 | 1 就是学习Haskell太疯狂了，让人常常质疑为啥不直接上Haskell算了。 |
d******e
发帖数: 2265 | 2 haskell的默认string 实现太慢了。比python慢10倍。
【在 p*****2 的大作中提到】
: 就是学习Haskell太疯狂了，让人常常质疑为啥不直接上Haskell算了。
|
l*********s
发帖数: 5409 | 3 It is trivial to use the non-lazy alternative.
【在 d******e 的大作中提到】
: haskell的默认string 实现太慢了。比python慢10倍。
|
d******e
发帖数: 2265 | 4 还有就是tree的实现比较弱吧。
做简单的东西和web service，haskell的确比较爽。
【在 l*********s 的大作中提到】
: It is trivial to use the non-lazy alternative.
:
|
w***g
发帖数: 5958 | 5 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
不断提醒自己我在用的是hack版，是有罪的.
我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
任”的态度。IO monad其实也是这个意思。
所谓纯FP的意思就是说我不是在做I/O，而是在对一堆I/O操作进行计算。其实
FP只是一种世界观而已，以haskell的眼光看过去, 从C++里面绝对能看到
一个一个的monad。
我早觉得haskell是一种很迂腐的语言。
【在 d******e 的大作中提到】
: haskell的默认string 实现太慢了。比python慢10倍。
|
p**r
发帖数: 5853 | 6 我去，虽然我没学习过，不过还是给跪了。
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
d****i
发帖数: 4809 | 7 哈哈，不错的见解。所以现实主义，实用主义是永恒的真理，“PHP是最好的语言”不
是玩笑话。
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
c*******9
发帖数: 9032 | 8 IO monad 龌龊？我觉得总的来说monad是优雅的方式。
”现实“也不是不可变的，“现实”要接近理想才是进步。
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
S*A
发帖数: 7142 | 9 非常赞同！迂腐非常贴切。
我另外一个观察就是，人们比较容易理解符合
execution flow 的代码。汇编不好读其中一个原因
就是跳来跳去人脑为了理解程序需要记住很多中间
状态。人脑是比较擅长理解过程式的状态，先做个，
下一部做那个，然后这个就变成了那个。
所以结构化的 if else，用空格 indent 来标明程序
机构，就是让程序的代码的阅读结构更加接近
execution flow。帮助人们理解，这一块是干什么的。
人脑不擅长高度抽象的推演和。有些描述很通用很
抽象，例如 meta class 这种，很多人理解就很费力。
人们通常需要看到这个抽象的东西如何实例话才能
理解。
Haskell 的整个就是代码非常不符合 execution flow。
这个给理解和调试都带来困难。Lisp 这类的语言出现
比 C 什么的早很多，甚至有硬件直接支持 Lisp 的。
但是一直推广比不上 C 这样的语言。这是其中一个
原因，这类 FP 比过程式语言难写难维护。
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
c*******9
发帖数: 9032 | 10 你不如说人脑更适合控制吃喝拉撒。
【在 S*A 的大作中提到】
: 非常赞同！迂腐非常贴切。
: 我另外一个观察就是，人们比较容易理解符合
: execution flow 的代码。汇编不好读其中一个原因
: 就是跳来跳去人脑为了理解程序需要记住很多中间
: 状态。人脑是比较擅长理解过程式的状态，先做个，
: 下一部做那个，然后这个就变成了那个。
: 所以结构化的 if else，用空格 indent 来标明程序
: 机构，就是让程序的代码的阅读结构更加接近
: execution flow。帮助人们理解，这一块是干什么的。
: 人脑不擅长高度抽象的推演和。有些描述很通用很
|
|
|
S*A
发帖数: 7142 | 11 这个的确是对的啊，每个人都会吃喝拉撒，没有什么困难吧。
但是不是每个人都适合编程。适合做程序员是人口里面的
一小部分。
【在 c*******9 的大作中提到】
: 你不如说人脑更适合控制吃喝拉撒。
|
d*******r
发帖数: 3299 | 12 Mark 了
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
l*********s
发帖数: 5409 | 13 That is why haskell most often helps you to become a better programmer ...
in another language. It makes you sharp : -)
【在 S*A 的大作中提到】
: 非常赞同！迂腐非常贴切。
: 我另外一个观察就是，人们比较容易理解符合
: execution flow 的代码。汇编不好读其中一个原因
: 就是跳来跳去人脑为了理解程序需要记住很多中间
: 状态。人脑是比较擅长理解过程式的状态，先做个，
: 下一部做那个，然后这个就变成了那个。
: 所以结构化的 if else，用空格 indent 来标明程序
: 机构，就是让程序的代码的阅读结构更加接近
: execution flow。帮助人们理解，这一块是干什么的。
: 人脑不擅长高度抽象的推演和。有些描述很通用很
|
p*****2
发帖数: 21240 | 14 确实 收获很大
【在 l*********s 的大作中提到】
: That is why haskell most often helps you to become a better programmer ...
: in another language. It makes you sharp : -)
|
l**********n
发帖数: 8443 | 15 I received such an email today from twitter:
We are seeking to bring on a number of Scala engineers to join Twitter's
backend Web team to help us build, scale and refine high-performance
scalable systems. |
n*w
发帖数: 3393 | 16 早期的lisp基本上都是解释的？比较慢性能不及c，尤其当时机器还慢得很。不知道为
什么lisp机没能成功。好像Java机也有人搞过？
还有人把lisp没能流行归结为没有标准的类库。
【在 S*A 的大作中提到】
: 非常赞同！迂腐非常贴切。
: 我另外一个观察就是，人们比较容易理解符合
: execution flow 的代码。汇编不好读其中一个原因
: 就是跳来跳去人脑为了理解程序需要记住很多中间
: 状态。人脑是比较擅长理解过程式的状态，先做个，
: 下一部做那个，然后这个就变成了那个。
: 所以结构化的 if else，用空格 indent 来标明程序
: 机构，就是让程序的代码的阅读结构更加接近
: execution flow。帮助人们理解，这一块是干什么的。
: 人脑不擅长高度抽象的推演和。有些描述很通用很
|
l******t
发帖数: 55733 | 17
这很逗比啊。你写个unit test就知道为什么IO应该都滚出去了
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
d*******r
发帖数: 3299 | 18 大牛展开说说?
这个不是 FP 的主要卖点吗
【在 l******t 的大作中提到】
:
: 这很逗比啊。你写个unit test就知道为什么IO应该都滚出去了
|
S*A
发帖数: 7142 | 19 这个是两回事。你可以说用汇编让你成为
更好程序员，因为没有好的功力写不了
上规模的汇编。
语言只是工具而已。
【在 l*********s 的大作中提到】
: That is why haskell most often helps you to become a better programmer ...
: in another language. It makes you sharp : -)
|
S*A
发帖数: 7142 | 20 lisp 和 haskell 一样，要写出高效率的
代码需要很高的功力，那种高效的做法
往往是不直观简单的。实际的机器不是
那么clean，现在lisp就算编译还是不如c。
因为距离机器码比较远。
【在 n*w 的大作中提到】
: 早期的lisp基本上都是解释的？比较慢性能不及c，尤其当时机器还慢得很。不知道为
: 什么lisp机没能成功。好像Java机也有人搞过？
: 还有人把lisp没能流行归结为没有标准的类库。
|
|
|
l******t
发帖数: 55733 | 21 当然是啊。我是说他的说法逗B
【在 d*******r 的大作中提到】
: 大牛展开说说?
: 这个不是 FP 的主要卖点吗
|
g******w
发帖数: 78 | 22
Well, some lisp implementations work very well now, such as sbcl, abcl, etc.
【在 S*A 的大作中提到】
: lisp 和 haskell 一样，要写出高效率的
: 代码需要很高的功力，那种高效的做法
: 往往是不直观简单的。实际的机器不是
: 那么clean，现在lisp就算编译还是不如c。
: 因为距离机器码比较远。
|
S*A
发帖数: 7142 | 23 我不相信 Lisp 编译出来的代码可以接近 C 生成的代码的运行效率。
你要是觉得可以，我给你个短 C 程序实验一下。是个有点实际运算
量的东西。
etc.
【在 g******w 的大作中提到】
:
: Well, some lisp implementations work very well now, such as sbcl, abcl, etc.
|
d****i
发帖数: 4809 | 24 C跟机器码指令集有着一一对应的关系，所以效率最高速度最快, 而lisp完全不同，想
用FP这种上层的逻辑来talk to底层的硬件，做梦。
【在 S*A 的大作中提到】
: 我不相信 Lisp 编译出来的代码可以接近 C 生成的代码的运行效率。
: 你要是觉得可以，我给你个短 C 程序实验一下。是个有点实际运算
: 量的东西。
:
: etc.
|
S*A
发帖数: 7142 | 25 没有到一一对应的地步。有很多机器码是没有 C 对应的东西的。
C 的变量需要分配到寄存器，有时候会 spill。
但是 C 很容易翻译到机器码是真的。C 可以当高级汇编用。
不需要 Lisp talk to 硬件，只是说实现一般的运算逻辑不可能
和 C 的运行效率高。假设都是非常好的程序员写的。
【在 d****i 的大作中提到】
: C跟机器码指令集有着一一对应的关系，所以效率最高速度最快, 而lisp完全不同，想
: 用FP这种上层的逻辑来talk to底层的硬件，做梦。
|
p*****2
发帖数: 21240 | 26 为什么偏要跟c比？
【在 S*A 的大作中提到】
: 没有到一一对应的地步。有很多机器码是没有 C 对应的东西的。
: C 的变量需要分配到寄存器，有时候会 spill。
: 但是 C 很容易翻译到机器码是真的。C 可以当高级汇编用。
: 不需要 Lisp talk to 硬件，只是说实现一般的运算逻辑不可能
: 和 C 的运行效率高。假设都是非常好的程序员写的。
|
n*****3
发帖数: 1584 | 27 clojure 啊
performance 狠不错啦
【在 S*A 的大作中提到】
: 我不相信 Lisp 编译出来的代码可以接近 C 生成的代码的运行效率。
: 你要是觉得可以，我给你个短 C 程序实验一下。是个有点实际运算
: 量的东西。
:
: etc.
|
l*********s
发帖数: 5409 | 28 They both produce native codes, I can't see why lisp must be much slower
than C.
However, the more high level is a language, the more difficult to turn its
performance, simply because there are so many stuffs hidden from you.
【在 S*A 的大作中提到】
: 没有到一一对应的地步。有很多机器码是没有 C 对应的东西的。
: C 的变量需要分配到寄存器，有时候会 spill。
: 但是 C 很容易翻译到机器码是真的。C 可以当高级汇编用。
: 不需要 Lisp talk to 硬件，只是说实现一般的运算逻辑不可能
: 和 C 的运行效率高。假设都是非常好的程序员写的。
|
g******w
发帖数: 78 | 29
lisp接近C还做不到，但确实performance已经不错了，譬如sbcl，benchmark game 可
以参考。考虑到一直只是那么几个人开发维护，it's amazing! And actually lisp (
sbcl) may be the fastest dynamic language.
【在 S*A 的大作中提到】
: 我不相信 Lisp 编译出来的代码可以接近 C 生成的代码的运行效率。
: 你要是觉得可以，我给你个短 C 程序实验一下。是个有点实际运算
: 量的东西。
:
: etc.
|
S*A
发帖数: 7142 | 30 你要试一下吗？
http://www.mitbbs.com/article_t1/Programming/31381809_0_4.html
测试数据生成在 80 楼， 完整 C 程序在 83 楼。
这个算法理论背景在这里，我用的算法就是dynamic 那个，
还不是空间最优的解法。空间用了 nxm：
http://www.ics.uci.edu/~eppstein/161/960229.html
欢迎用 Closure 和 Scala 或者 Lisp 来做同样的东西我们来看看
实现的代码运行速度怎样。
有代码可以比较大家就有感觉这个非常接近 C 的 performance 到底
是接近到什么程度。
【在 l*********s 的大作中提到】
: They both produce native codes, I can't see why lisp must be much slower
: than C.
: However, the more high level is a language, the more difficult to turn its
: performance, simply because there are so many stuffs hidden from you.
|
|
|
z******g
发帖数: 271 | 31 说的真好，越往下越是一坨
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
a*****e
发帖数: 1700 | 32 你混淆了好几个概念，貌似有道理，其实错得很远。
Haskell 语言本身纯，和它依赖库来提供高效实现，没有任何冲突。像 int, string
这种，本来就是不需要放到语言设计里东西。用 ByteString 或者 Text 不会有任何
hack 的感觉，和使用其它的 library 一样使用，我不知道你这种说法有什么依据，哪
些地方 hack 了？用第三方库能用出有罪的感觉，我真是无言以对...
Haskell 用 Monad 来给副作用之间画出界限，比起 imperative 语言里面随便把副作
用堆在一起，是一种进步。你可以说你不 care，但是需要 care 的时候，Haskell 可
以帮你清楚的分开副作用和无副作用，imperative 语言做不到。
的确，IO Monad 被不少搞理论的人诟病，说是 hack，但是你首先要弄清楚 IO Monad
只是众多 Monad 中的一种，Haskell 里面处理 IO 可以用 IO Monad，也可以用别的方
式，并没有强迫你使用 IO Monad，说到底，用 IO Monad 都是库，不是语言本身，用
不用可以由用户自己选择。与此相关的研究一直在向前发展，并没有被 IO Monad 束缚
住。
你所谓的“这不是我的责任”，我也不知道这句话是从何说起。如果要说一个 Haskell
程序员和一个 Python 程序员有什么责任方面的差别，如果最终目的都是要尽可能确
保程序的 type safety, effect safety, thread safety 种种特征，显然 Haskell 程
序员可以从语言本身得到各种帮助，而不是像 Python 程序员那样唯一的依仗只有测试。
【在 w***g 的大作中提到】
: 因为默认string是纯haskell实现的。他们的意思就是你既可以用纯而慢的方法，
: 也可以用快的hack。从有两个string这个现实可以看出在数学上的干净性和
: 性能这两者的取舍间haskell选择了前者。haskell的很多东西都有两个版本，
: 一个是FP的教科书版本，一个是高性能的hack版。然后强迫你在写程序的时候
: 不断提醒自己我在用的是hack版，是有罪的.
: 我看不出纯FP版的string除了证明这种实现很慢以外有任何必要。我的观点是
: 现实世界和底层硬件本身是不干净的，好的编程语言则能够把不干净的抽象成
: 干净的呈现给用户，至于语言本身的实现龌龊点关系不大。Haskell太过
: 注重把语言(包括runtime和库)本身的实现搞得很纯很干净，结果导致一些显示
: 现实世界龌龊性的API的存在，并且通过其命名方式表示出一副“这不是我的责
|
w***g
发帖数: 5958 | 33 请科普下Haskell中不用IO monad的IO方式，在GHC中能用即可。
别的都是个人taste问题，没法argue。
Monad
【在 a*****e 的大作中提到】
: 你混淆了好几个概念，貌似有道理，其实错得很远。
: Haskell 语言本身纯，和它依赖库来提供高效实现，没有任何冲突。像 int, string
: 这种，本来就是不需要放到语言设计里东西。用 ByteString 或者 Text 不会有任何
: hack 的感觉，和使用其它的 library 一样使用，我不知道你这种说法有什么依据，哪
: 些地方 hack 了？用第三方库能用出有罪的感觉，我真是无言以对...
: Haskell 用 Monad 来给副作用之间画出界限，比起 imperative 语言里面随便把副作
: 用堆在一起，是一种进步。你可以说你不 care，但是需要 care 的时候，Haskell 可
: 以帮你清楚的分开副作用和无副作用，imperative 语言做不到。
: 的确，IO Monad 被不少搞理论的人诟病，说是 hack，但是你首先要弄清楚 IO Monad
: 只是众多 Monad 中的一种，Haskell 里面处理 IO 可以用 IO Monad，也可以用别的方
|
a*****e
发帖数: 1700 | 34 如果你是说底层，其实 IO Monad 就是 ST Monad 封装了诸多 FFI 而已，不想用 IO
Monad，可以直接调用 FFI.
如果你是说别的抽象方式，可以看看 effect handler
http://okmij.org/ftp/Haskell/extensible/
domain specific 方面，比如 arrow FRP 里面可以用 wormhole 实现并行互不干扰 IO
http://haskell.cs.yale.edu/?post_type=publication&p=802
【在 w***g 的大作中提到】
: 请科普下Haskell中不用IO monad的IO方式，在GHC中能用即可。
: 别的都是个人taste问题，没法argue。
:
: Monad
|
a*****e
发帖数: 1700 | 35 回顾 Haskell 发展历史，IO Monad 还是后来出现的。起初是用的 CPS (continuation
passing style) 的方式来做的，后来 CPS Monad 被发现后，就都使用 Monad 来做了
。使用 ST Monad 封装则更靠后一些，是 SPJ 搞的，因为实在是太方便了，各种
effect 直接都封在 IO Monad 里面像 imperative 语言一样都堆在一起就好了，这种
choose the easy way out 的做法导致它被人(主要是 theoretician)诟病至今。
IO
【在 a*****e 的大作中提到】
: 如果你是说底层，其实 IO Monad 就是 ST Monad 封装了诸多 FFI 而已，不想用 IO
: Monad，可以直接调用 FFI.
: 如果你是说别的抽象方式，可以看看 effect handler
: http://okmij.org/ftp/Haskell/extensible/
: domain specific 方面，比如 arrow FRP 里面可以用 wormhole 实现并行互不干扰 IO
: http://haskell.cs.yale.edu/?post_type=publication&p=802
|
w***g
发帖数: 5958 | 36 我怎么记得FFI也是用IO monad实现的。比如下面的页面
https://www.haskell.org/haskellwiki/FFI_Introduction
C实现的一个void set_icanon(int fd)，到了haskell就变成带IO的了：
foreign import ccall "set_icanon" set_icanon :: CInt -> IO ()
难道是我查得不对？
你这个claim有可能颠覆我的三观，不得不问问清楚。
IO
【在 a*****e 的大作中提到】
: 如果你是说底层，其实 IO Monad 就是 ST Monad 封装了诸多 FFI 而已，不想用 IO
: Monad，可以直接调用 FFI.
: 如果你是说别的抽象方式，可以看看 effect handler
: http://okmij.org/ftp/Haskell/extensible/
: domain specific 方面，比如 arrow FRP 里面可以用 wormhole 实现并行互不干扰 IO
: http://haskell.cs.yale.edu/?post_type=publication&p=802
|
a*****e
发帖数: 1700 | 37 wdong 下面这段话写得非常好，我非常同意：
FP 主要理论就是 function is composable，推论是 that can be a great way of
programming。
前半句无可非议，后半句有争议。但是不可否认的是，the (re)discovery of Monad
是 FP 在这条路上的一个重要贡献。它的指导意义在于，I/Os do not compose like
functions, they compose like Monads。
这是一个 profound understanding of how program works，无论使用什么编程语言，
它的结构和特征都在那里。
【在 w***g 的大作中提到】
: 我怎么记得FFI也是用IO monad实现的。比如下面的页面
: https://www.haskell.org/haskellwiki/FFI_Introduction
: C实现的一个void set_icanon(int fd)，到了haskell就变成带IO的了：
: foreign import ccall "set_icanon" set_icanon :: CInt -> IO ()
: 难道是我查得不对？
: 你这个claim有可能颠覆我的三观，不得不问问清楚。
:
: IO
|
a*****e
发帖数: 1700 | 38 你的理解有一点点误差。没有任何理由可以阻止你写出如下声明：
foreign import ccall "set_icanon" set_icanon :: CInt -> ()
然后就可以像调用纯函数一样调用 I/O routine 啦！
之所以 FFI 提供 IO () 这样的声明方式，是为了立刻将有副作用的 FFI 调用封装到
IO Monad 里面去。要是想跳出 IO Monad，完全可以不用。
【在 w***g 的大作中提到】
: 我怎么记得FFI也是用IO monad实现的。比如下面的页面
: https://www.haskell.org/haskellwiki/FFI_Introduction
: C实现的一个void set_icanon(int fd)，到了haskell就变成带IO的了：
: foreign import ccall "set_icanon" set_icanon :: CInt -> IO ()
: 难道是我查得不对？
: 你这个claim有可能颠覆我的三观，不得不问问清楚。
:
: IO
|
w***g
发帖数: 5958 | 39 抱着哲学探讨的态度做下面的回复，不是要拆FP community的台，而是试图指出FP目前
存在的问题。
你说I/O compose like monads我觉得还不够接近本质。Monad的一个牛B的应用是它可
以很干净地描述parsing，或者说是处理text composition。你说的I/O composition确
切地指的应该是imperative langauage里的I/O source code composition (Haskell里
的IO就是IO monad，没啥like不like的)。而source code composition只是text
composition的一个特例，所以自然而然也就可以用monad表述了。在haskell里写I/O
monad的过程本质上是一个人肉parse一段假想的imperative code并转换成用monad表出
的中间数据结构(haskell程序)的过程。Monad能用来做I/O不是因为monad能描述I/O本
身，而是下面三点的自然推论：
1. monad能parse text。
2. imperative language能被parse。
3. I/O逻辑能用imperative language写出来。(有啥I/O逻辑不能用imperative
language写出来的？这个我也想不出来。）
你说的“profound understanding of how program works”的内容应该是：FP研究了
这么多年终于发现了programs是一些可以被parse的文本文件。等于啥都没说。(符合
范畴论的一般套路。）
为了检验上面的论断，我给出由上面的逻辑可以直接得到的两个推论，大家看是不是这
么回事。
1. 不光是IO，也不光是imperative language。不管是什么语言，只要能写的出来对应
的编译器(这个语言能被parse），那么这个语言里面对应的东西就能用monad写出来。
比如exception handling, java里的annotation，在imperative language里还不怎么
流行的aspect oriented programming，这些都能用monad写出来。这个转换如果不考虑
语法糖的话应该是可以用程序自动实现的。
2. Haskell里所有涉及到IO monad的代码都有等价的imperative language实现。
如果说monad有什么问题，那就是这个概念太抽象了，能做的事情太多了，一般人可以
掌握
IO monad, Maybe, List等各种monad的用法，但是要说精通不带修饰的“monad”那就跟
说我精通写文本文件一样是没有意义的。Monad在haskell里的作用是发明新的user-
defined
programming construction。
靠，abstract nonsense。
【在 a*****e 的大作中提到】
: wdong 下面这段话写得非常好，我非常同意：
:
: FP 主要理论就是 function is composable，推论是 that can be a great way of
: programming。
: 前半句无可非议，后半句有争议。但是不可否认的是，the (re)discovery of Monad
: 是 FP 在这条路上的一个重要贡献。它的指导意义在于，I/Os do not compose like
: functions, they compose like Monads。
: 这是一个 profound understanding of how program works，无论使用什么编程语言，
: 它的结构和特征都在那里。
|
w***g
发帖数: 5958 | 40 我在GHC里试了，确实能正常运行。这个我以前确实不知道。如果能人肉保证函数没有
side effect的话是可以不加IO的。但是如果函数确实有side effect的话，那是有可能
引起错误的。所以你说的通过FFI进行I/O我还是无法接受。事实上main的类型就已经被
定死成IO ()，IO monad是绕不过去的。
到
【在 a*****e 的大作中提到】
: 你的理解有一点点误差。没有任何理由可以阻止你写出如下声明：
: foreign import ccall "set_icanon" set_icanon :: CInt -> ()
: 然后就可以像调用纯函数一样调用 I/O routine 啦！
: 之所以 FFI 提供 IO () 这样的声明方式，是为了立刻将有副作用的 FFI 调用封装到
: IO Monad 里面去。要是想跳出 IO Monad，完全可以不用。
|
|
|
a*****e
发帖数: 1700 | 41 我不是很理解你说的用 monad 描述 parsing 和 monad 表述 I/O 有什么关系，
是说 parser combinator 可以用 monad 实现吗？parser combinator 同样可以用
applicative 或者 arrows 实现，和 monad 的实现各有优劣。
我说 I/O compose like monads 前面还要加一个定语: sequential，这是因为需要
确保副作用发生的先后顺序。不加限制的 function composition 做不到这点，但
不加限制的 monad composition 可以做到这点。
而且 text composition 明显是个 monoid，先后顺序不重要，结果一致就好。
为什么说 sequential I/O 可以用 Monad 表述，是因为 sequential I/O 之间的
composition 满足 monad laws，而不是源程序可以写成什么样子，同时它也
不依赖于语言本身的求值顺序等特征。
【在 w***g 的大作中提到】
: 抱着哲学探讨的态度做下面的回复，不是要拆FP community的台，而是试图指出FP目前
: 存在的问题。
: 你说I/O compose like monads我觉得还不够接近本质。Monad的一个牛B的应用是它可
: 以很干净地描述parsing，或者说是处理text composition。你说的I/O composition确
: 切地指的应该是imperative langauage里的I/O source code composition (Haskell里
: 的IO就是IO monad，没啥like不like的)。而source code composition只是text
: composition的一个特例，所以自然而然也就可以用monad表述了。在haskell里写I/O
: monad的过程本质上是一个人肉parse一段假想的imperative code并转换成用monad表出
: 的中间数据结构(haskell程序)的过程。Monad能用来做I/O不是因为monad能描述I/O本
: 身，而是下面三点的自然推论：
|
w***g
发帖数: 5958 | 42 是我搞混了，好久没用haskell了，都忘干净了。你把我文中的monad换成applicative
或这arrow，只要还能parse程序，那么我说的一切就应该还成立。
【在 a*****e 的大作中提到】
: 我不是很理解你说的用 monad 描述 parsing 和 monad 表述 I/O 有什么关系，
: 是说 parser combinator 可以用 monad 实现吗？parser combinator 同样可以用
: applicative 或者 arrows 实现，和 monad 的实现各有优劣。
: 我说 I/O compose like monads 前面还要加一个定语: sequential，这是因为需要
: 确保副作用发生的先后顺序。不加限制的 function composition 做不到这点，但
: 不加限制的 monad composition 可以做到这点。
: 而且 text composition 明显是个 monoid，先后顺序不重要，结果一致就好。
: 为什么说 sequential I/O 可以用 Monad 表述，是因为 sequential I/O 之间的
: composition 满足 monad laws，而不是源程序可以写成什么样子，同时它也
: 不依赖于语言本身的求值顺序等特征。
|
a*****e
发帖数: 1700 | 43 "有side effect的话，那是有可能引起错误的" 的前提是对 FFI 的调用不加限制。
IO Monad = ST Monad + RealWorld，这是一种限制方式。
但显然有其它限制方式，在发明出 IO Monad 以前 Main 可不是现在这个 type.
【在 w***g 的大作中提到】
: 我在GHC里试了，确实能正常运行。这个我以前确实不知道。如果能人肉保证函数没有
: side effect的话是可以不加IO的。但是如果函数确实有side effect的话，那是有可能
: 引起错误的。所以你说的通过FFI进行I/O我还是无法接受。事实上main的类型就已经被
: 定死成IO ()，IO monad是绕不过去的。
:
: 到
|
w***g
发帖数: 5958 | 44 如果仅仅是为了描述sequential I/O的话根本就不需要monad啥的。
你再想想看，monad要解决的是要描述由顺序选择循环这三个基本控制结构
可以写出来的IO逻辑。运行这个IO逻辑才产生了一系列sequantial I/O。
【在 a*****e 的大作中提到】
: 我不是很理解你说的用 monad 描述 parsing 和 monad 表述 I/O 有什么关系，
: 是说 parser combinator 可以用 monad 实现吗？parser combinator 同样可以用
: applicative 或者 arrows 实现，和 monad 的实现各有优劣。
: 我说 I/O compose like monads 前面还要加一个定语: sequential，这是因为需要
: 确保副作用发生的先后顺序。不加限制的 function composition 做不到这点，但
: 不加限制的 monad composition 可以做到这点。
: 而且 text composition 明显是个 monoid，先后顺序不重要，结果一致就好。
: 为什么说 sequential I/O 可以用 Monad 表述，是因为 sequential I/O 之间的
: composition 满足 monad laws，而不是源程序可以写成什么样子，同时它也
: 不依赖于语言本身的求值顺序等特征。
|
w***g
发帖数: 5958 | 45 靠，我竟然悟到了这么精辟的道理。待我用英语把这个好好写写发到博客上。
【在 w***g 的大作中提到】
: 抱着哲学探讨的态度做下面的回复，不是要拆FP community的台，而是试图指出FP目前
: 存在的问题。
: 你说I/O compose like monads我觉得还不够接近本质。Monad的一个牛B的应用是它可
: 以很干净地描述parsing，或者说是处理text composition。你说的I/O composition确
: 切地指的应该是imperative langauage里的I/O source code composition (Haskell里
: 的IO就是IO monad，没啥like不like的)。而source code composition只是text
: composition的一个特例，所以自然而然也就可以用monad表述了。在haskell里写I/O
: monad的过程本质上是一个人肉parse一段假想的imperative code并转换成用monad表出
: 的中间数据结构(haskell程序)的过程。Monad能用来做I/O不是因为monad能描述I/O本
: 身，而是下面三点的自然推论：
|
a*****e
发帖数: 1700 | 46 "FP研究了这么多年终于发现了programs是一些可以被parse的文本文件。等于啥都没说
。"
上面这句话，我觉得有必要单独拿出来讲讲。
首先，我们谈的是 composition，而不是源代码写成 text 还是 AST。那么我问几个问
题：
1. (A ; B) ; C 等价于 A ; (B ; C) 吗？
2. A ; B 等价于 B ; A 吗？
3. A @ (B ; C) 等价于 (A @ B) ; (A @ C) 吗？
这里出现的 A B C 代表什么，而括号、分号、@号又代表什么，如果不定义清楚则
无法回答。
如果 ABC 代表自然数，括号表示优先级，分号是加法，@是乘法，那么三条对应的就是
结合律，交换律，分配律，都是满足的。
如果 ABC 代表互不干扰（也不先后干扰）的 Unix 进程，分号是并行执行（share
input)，@ 表示 pipe，那么三条也都成立。但如果 ABC 是任意procedure，那么有可
能三条都不成立。
FP研究了这么多年终于发现了programs是可以表述为类型 M a，M 代表了副作用，a 代
表返回值。然后有三个特殊操作：
return :: a -> M a
fmap :: (a -> b) -> M a -> M b
join :: M (M a) -> M a
加上普通的函数操作就可以完整表述任意 imperative program 的组合方式，且满足以
下定律：
join . fmap join ≡ join . join
join . fmap return ≡ join . return = id
join . fmap (fmap f) ≡ fmap f . join
无需知道 M 的实现，无需知道语言的求值顺序，就可以对程序本身进行等价变换，用
于证明或者优化。
这，难道不是一个进步？
【在 w***g 的大作中提到】
: 抱着哲学探讨的态度做下面的回复，不是要拆FP community的台，而是试图指出FP目前
: 存在的问题。
: 你说I/O compose like monads我觉得还不够接近本质。Monad的一个牛B的应用是它可
: 以很干净地描述parsing，或者说是处理text composition。你说的I/O composition确
: 切地指的应该是imperative langauage里的I/O source code composition (Haskell里
: 的IO就是IO monad，没啥like不like的)。而source code composition只是text
: composition的一个特例，所以自然而然也就可以用monad表述了。在haskell里写I/O
: monad的过程本质上是一个人肉parse一段假想的imperative code并转换成用monad表出
: 的中间数据结构(haskell程序)的过程。Monad能用来做I/O不是因为monad能描述I/O本
: 身，而是下面三点的自然推论：
|
a*****e
发帖数: 1700 | 47 选择与循环和 monad 无关。前者依赖惰性求值，后者依赖递归。
【在 w***g 的大作中提到】
: 如果仅仅是为了描述sequential I/O的话根本就不需要monad啥的。
: 你再想想看，monad要解决的是要描述由顺序选择循环这三个基本控制结构
: 可以写出来的IO逻辑。运行这个IO逻辑才产生了一系列sequantial I/O。
|
a*****e
发帖数: 1700 | 48 回头又读一遍，我大概知道你要说什么了。
Monad 带来最直接，也最表层的影响，是语法上的。能够把一段代码作为 first class
citizen 对待，这其实也是一个 profound change。
Fist class citizen 的特点：可以作为参数传递，作为返回值，可以赋值给变量。
http://en.wikipedia.org/wiki/First-class_citizen
谈到组合方式，如果对象是 function，可以写成 f(g(x))，如果对象是代码，可以写
成 { A; B } 这在 C 语言里都能做到。问题是 C 和大部分语言里，只有 f g x 可以
是变量，而 A 和 B 则不可以。f(g(x)) 可以求值然后赋予一个变量，A; B 组合的结
果（一段新代码）则不可以赋值给变量。
猛一看似乎不好理解，但一旦接受了，则是一个非常自然的结果。就像越来越多的语言
都已经实现了 lambda 也即 first class function 之后，我相信，first class code
也即 IO Monad 也会逐渐流行起来。
【在 w***g 的大作中提到】
: 靠，我竟然悟到了这么精辟的道理。待我用英语把这个好好写写发到博客上。
|
w***g
发帖数: 5958 | 49 不知道你对C语言里面的函数指针有什么看法，符合你说的作为参数传递，作为返回值
，可以赋给变量三个条件。C++里面的lambda只是函数指针的语法糖而已。java,
python这些语言里的lambda也都更像函数指针的语法糖。这些都是伪functional
programming，只是用了一个lambda的形式而已。C++里面的模板匹配才是真正的FP，基
本上就是一个原生态的haskell, 差了点语法糖而已。下面这个帖子就是如何用C++模板
实现monad:
http://bartoszmilewski.com/2011/07/11/monads-in-c/
所谓的functional的精髓我觉得是代码没有side effect，这一点其实只能在编译时做
到。不是说搞一些叫做function或者叫做lambda的东西在语言里就是functional了。
C++那批发明者似乎没有搞FP的，但是他们能从对性能的追求和对语言的直觉搞出来这
么一套系统，不得不说是太牛B了。甩java好几条街。
(这个观点以前在这个版上被批判过，大家需要谨慎对待。）
class
【在 a*****e 的大作中提到】
: 回头又读一遍，我大概知道你要说什么了。
: Monad 带来最直接，也最表层的影响，是语法上的。能够把一段代码作为 first class
: citizen 对待，这其实也是一个 profound change。
: Fist class citizen 的特点：可以作为参数传递，作为返回值，可以赋值给变量。
: http://en.wikipedia.org/wiki/First-class_citizen
: 谈到组合方式，如果对象是 function，可以写成 f(g(x))，如果对象是代码，可以写
: 成 { A; B } 这在 C 语言里都能做到。问题是 C 和大部分语言里，只有 f g x 可以
: 是变量，而 A 和 B 则不可以。f(g(x)) 可以求值然后赋予一个变量，A; B 组合的结
: 果（一段新代码）则不可以赋值给变量。
: 猛一看似乎不好理解，但一旦接受了，则是一个非常自然的结果。就像越来越多的语言
|
d****i
发帖数: 4809 | 50 大牛高见，对于鼓吹FP的原教旨主义者，还是得像你这样的对传统大众编程语言和FP都
认知很深的人来反驳他们自以为是的谬论来以正视听。
只是
mini
【在 w***g 的大作中提到】
: 不知道你对C语言里面的函数指针有什么看法，符合你说的作为参数传递，作为返回值
: ，可以赋给变量三个条件。C++里面的lambda只是函数指针的语法糖而已。java,
: python这些语言里的lambda也都更像函数指针的语法糖。这些都是伪functional
: programming，只是用了一个lambda的形式而已。C++里面的模板匹配才是真正的FP，基
: 本上就是一个原生态的haskell, 差了点语法糖而已。下面这个帖子就是如何用C++模板
: 实现monad:
: http://bartoszmilewski.com/2011/07/11/monads-in-c/
: 所谓的functional的精髓我觉得是代码没有side effect，这一点其实只能在编译时做
: 到。不是说搞一些叫做function或者叫做lambda的东西在语言里就是functional了。
: C++那批发明者似乎没有搞FP的，但是他们能从对性能的追求和对语言的直觉搞出来这
|
|
|
p***o
发帖数: 1252 | 51 C++的lambda比函数指针的语法糖还是高级一些的 ...
【在 w***g 的大作中提到】
: 不知道你对C语言里面的函数指针有什么看法，符合你说的作为参数传递，作为返回值
: ，可以赋给变量三个条件。C++里面的lambda只是函数指针的语法糖而已。java,
: python这些语言里的lambda也都更像函数指针的语法糖。这些都是伪functional
: programming，只是用了一个lambda的形式而已。C++里面的模板匹配才是真正的FP，基
: 本上就是一个原生态的haskell, 差了点语法糖而已。下面这个帖子就是如何用C++模板
: 实现monad:
: http://bartoszmilewski.com/2011/07/11/monads-in-c/
: 所谓的functional的精髓我觉得是代码没有side effect，这一点其实只能在编译时做
: 到。不是说搞一些叫做function或者叫做lambda的东西在语言里就是functional了。
: C++那批发明者似乎没有搞FP的，但是他们能从对性能的追求和对语言的直觉搞出来这
|
c*******9
发帖数: 9032 | 52 函数指针和lamba完全不同的楖念，它不包合对所指如何操作的信息。用模板可以实现
FP，但不等于模板匹配就是Fp。汇用编什么Fp也都能实现。这样的想法就像知道了变量
可以替换
就以为自己掌握了代数学。
【在 w***g 的大作中提到】
: 不知道你对C语言里面的函数指针有什么看法，符合你说的作为参数传递，作为返回值
: ，可以赋给变量三个条件。C++里面的lambda只是函数指针的语法糖而已。java,
: python这些语言里的lambda也都更像函数指针的语法糖。这些都是伪functional
: programming，只是用了一个lambda的形式而已。C++里面的模板匹配才是真正的FP，基
: 本上就是一个原生态的haskell, 差了点语法糖而已。下面这个帖子就是如何用C++模板
: 实现monad:
: http://bartoszmilewski.com/2011/07/11/monads-in-c/
: 所谓的functional的精髓我觉得是代码没有side effect，这一点其实只能在编译时做
: 到。不是说搞一些叫做function或者叫做lambda的东西在语言里就是functional了。
: C++那批发明者似乎没有搞FP的，但是他们能从对性能的追求和对语言的直觉搞出来这
|
a*****e
发帖数: 1700 | 53 指针当然是 first class，但是函数指针不能够方便地组合，比如在 Haskell 里面写
f . g 的结果就是一个新函数，换到 C++ 里面就没有这么方便。
新的 C++ 标准提供了 lambda 语法糖，虽然需要手工指定 environment variable 也
不方便，但我觉得比有些其它语言里的方式要好。
总的来说，lambda 已经进入了主流语言的语法，是一件好事。但大部分非函数语言都
无法提供一个高效的实现。
另外，真正明晰的函数闭包语义需要严格区分 reference 和 value，这点上在
javascript, ruby, python, perl, 包括 swift 里面，都做得不好，甚至不如 C++。
最后的结果就是 lambda 和 closure 不好用，主要用途也都是充当一个回调的语法糖
而已。归根结底还是因为语义不明晰，这些语言设计者还不能够理解函数语言的精髓。
【在 w***g 的大作中提到】
: 不知道你对C语言里面的函数指针有什么看法，符合你说的作为参数传递，作为返回值
: ，可以赋给变量三个条件。C++里面的lambda只是函数指针的语法糖而已。java,
: python这些语言里的lambda也都更像函数指针的语法糖。这些都是伪functional
: programming，只是用了一个lambda的形式而已。C++里面的模板匹配才是真正的FP，基
: 本上就是一个原生态的haskell, 差了点语法糖而已。下面这个帖子就是如何用C++模板
: 实现monad:
: http://bartoszmilewski.com/2011/07/11/monads-in-c/
: 所谓的functional的精髓我觉得是代码没有side effect，这一点其实只能在编译时做
: 到。不是说搞一些叫做function或者叫做lambda的东西在语言里就是functional了。
: C++那批发明者似乎没有搞FP的，但是他们能从对性能的追求和对语言的直觉搞出来这
|
a*****e
发帖数: 1700 | 54 另外针对 C++ 的模板，你当然可以说它是 FP，它也足够强大，turing complete 么。
甚至 C 里面的宏，你也可以说它是 FP，因为都是 stateless rewrite rules 么。
可以这么做，但不代表好用，至少我是尽量避免使用 C++ 模板，因为错误信息完全看
不懂。当然我不敢说自己是个多好的 C++ 程序员，我写 C 甚至 Java 都比 C++ 时间
长多了。
最后，你给的链接是 Bartosz Milewski 的文章，这哥们早几年前就从 C++ zealot 变
成 Haskell convert 了，现在为 FP Complete 工作，最近在忙着写 category theory
的书。
【在 w***g 的大作中提到】
: 不知道你对C语言里面的函数指针有什么看法，符合你说的作为参数传递，作为返回值
: ，可以赋给变量三个条件。C++里面的lambda只是函数指针的语法糖而已。java,
: python这些语言里的lambda也都更像函数指针的语法糖。这些都是伪functional
: programming，只是用了一个lambda的形式而已。C++里面的模板匹配才是真正的FP，基
: 本上就是一个原生态的haskell, 差了点语法糖而已。下面这个帖子就是如何用C++模板
: 实现monad:
: http://bartoszmilewski.com/2011/07/11/monads-in-c/
: 所谓的functional的精髓我觉得是代码没有side effect，这一点其实只能在编译时做
: 到。不是说搞一些叫做function或者叫做lambda的东西在语言里就是functional了。
: C++那批发明者似乎没有搞FP的，但是他们能从对性能的追求和对语言的直觉搞出来这
|
w***g
发帖数: 5958 | 55 文章作者convert并不能说明什么。要搞programming language的话基本上就得用
haskell。
C++的模板是有类型系统的，现在可能不完善吧，但是至少是可以完善的。
另外C++里的lambda就是语法糖，所有的lambda都可以通过定义一个重载了()方法的类
来实现。本质上就是带一个隐含this指针参数的函数指针。你说的子程序签套运算我怀
疑C++11也可以用库来实现，但都不能避免side effect的问题。
我Google了下FP的定义
In computer science, functional programming is a programming paradigm, a
style of building the structure and elements of computer programs, that
treats computation as the evaluation of mathematical functions and avoids
changing-state and mutable data.
我觉得关键还是avoid changing-state and mutable data。所有这些带lambda的语言
基本上都不支持functional data structure。我觉得他们离FP还差得很远。
我最近写C++就碰到这么一个case。就是一个递增的数据结构有n个线程读，有一个
线程写，如果有functional data structure可以用的话就会非常爽，因为做
snapshot的成本为0. 最后解决方案只能是维护两个版本的数据结构，一个读一个写，
写完了swap一下指针。
theory
【在 a*****e 的大作中提到】
: 另外针对 C++ 的模板，你当然可以说它是 FP，它也足够强大，turing complete 么。
: 甚至 C 里面的宏，你也可以说它是 FP，因为都是 stateless rewrite rules 么。
: 可以这么做，但不代表好用，至少我是尽量避免使用 C++ 模板，因为错误信息完全看
: 不懂。当然我不敢说自己是个多好的 C++ 程序员，我写 C 甚至 Java 都比 C++ 时间
: 长多了。
: 最后，你给的链接是 Bartosz Milewski 的文章，这哥们早几年前就从 C++ zealot 变
: 成 Haskell convert 了，现在为 FP Complete 工作，最近在忙着写 category theory
: 的书。
|
N******K
发帖数: 10202 | 56 fp语言能用来做数字电路编程么？
能用来做控制系统编程么？
【在 a*****e 的大作中提到】
: "FP研究了这么多年终于发现了programs是一些可以被parse的文本文件。等于啥都没说
: 。"
: 上面这句话，我觉得有必要单独拿出来讲讲。
: 首先，我们谈的是 composition，而不是源代码写成 text 还是 AST。那么我问几个问
: 题：
: 1. (A ; B) ; C 等价于 A ; (B ; C) 吗？
: 2. A ; B 等价于 B ; A 吗？
: 3. A @ (B ; C) 等价于 (A @ B) ; (A @ C) 吗？
: 这里出现的 A B C 代表什么，而括号、分号、@号又代表什么，如果不定义清楚则
: 无法回答。
|
w***g
发帖数: 5958 | 57 应该可以的。我上面帖子已经论证了FP里面用monad可以实现
所有可以parse的语言的功能。Haskell用来实现一个类似
verilog或者VHDL之类的系统应该也能做得很漂亮。而且
数字电路编程完全对应编译期计算，没有状态，很容易做
到纯functional。
【在 N******K 的大作中提到】
: fp语言能用来做数字电路编程么？
: 能用来做控制系统编程么？
|
a*****e
发帖数: 1700 | 58 Google Bluespec.
这个是个比 Verilog 抽象层面高一点的商业系统，最初的 surface language 是比较
彻底的 FP，后来为了迎合大多数 C/C++ 背景的程序员，改成了现在这个样子，但本质
还是 FP 没错。
【在 N******K 的大作中提到】
: fp语言能用来做数字电路编程么？
: 能用来做控制系统编程么？
|
d****i
发帖数: 4809 | 59 时序逻辑电路都有状态，怎么可能没有状态？看不出haskell怎么可能实现VHDL和
Verilog的功能
【在 w***g 的大作中提到】
: 应该可以的。我上面帖子已经论证了FP里面用monad可以实现
: 所有可以parse的语言的功能。Haskell用来实现一个类似
: verilog或者VHDL之类的系统应该也能做得很漂亮。而且
: 数字电路编程完全对应编译期计算，没有状态，很容易做
: 到纯functional。
|
a*****e
发帖数: 1700 | 60 的确是这样。声称自己是 FP 语言的通常有两类，一种是支持 first class function
，一种是支持 immutable by default 的。比如 Single Assignment C (SAC)，都不支
持 higher-order function，但通常也被认为是 FP。
【在 w***g 的大作中提到】
: 文章作者convert并不能说明什么。要搞programming language的话基本上就得用
: haskell。
: C++的模板是有类型系统的，现在可能不完善吧，但是至少是可以完善的。
: 另外C++里的lambda就是语法糖，所有的lambda都可以通过定义一个重载了()方法的类
: 来实现。本质上就是带一个隐含this指针参数的函数指针。你说的子程序签套运算我怀
: 疑C++11也可以用库来实现，但都不能避免side effect的问题。
: 我Google了下FP的定义
: In computer science, functional programming is a programming paradigm, a
: style of building the structure and elements of computer programs, that
: treats computation as the evaluation of mathematical functions and avoids
|
|
|
w***g
发帖数: 5958 | 61 电路运行的时候有状态，但是电路本身是个静态的东西，一点烧成了就不能变了。
绝对是functional的。(对应haskell里的main，main这个IO monad本身是个静态的东西，
程序一旦编译完成就不能再变了。)
【在 d****i 的大作中提到】
: 时序逻辑电路都有状态，怎么可能没有状态？看不出haskell怎么可能实现VHDL和
: Verilog的功能
|
d****i
发帖数: 4809 | 62 你这个指的是物理上的状态，那当然是静态，但是数学上的状态电路都有，就是f(t)取
决与f(t-1),....f(t-N)的所有状态。
西，
【在 w***g 的大作中提到】
: 电路运行的时候有状态，但是电路本身是个静态的东西，一点烧成了就不能变了。
: 绝对是functional的。(对应haskell里的main，main这个IO monad本身是个静态的东西，
: 程序一旦编译完成就不能再变了。)
|
a*****e
发帖数: 1700 | 63 支持状态不代表不是 FP 啊！你需要思考一下，状态本身是否需要用 destructive
update 来建模？
对信号最直观的抽象就是把它们看作关于时间的函数: Signal a = Time -> a 这个是
所谓 FRP (Functional Reactive Programming) 的核心。
【在 d****i 的大作中提到】
: 时序逻辑电路都有状态，怎么可能没有状态？看不出haskell怎么可能实现VHDL和
: Verilog的功能
|
w***g
发帖数: 5958 | 64 VHDL和verilog只是描述电路连线的啊。你说的这个是simulation的功能吧？
用haskell写完电路描述后用runtime对它做simulation，我觉得应该没问题。
【在 d****i 的大作中提到】
: 你这个指的是物理上的状态，那当然是静态，但是数学上的状态电路都有，就是f(t)取
: 决与f(t-1),....f(t-N)的所有状态。
:
: 西，
|
a*****e
发帖数: 1700 | 65 这个领域的确有这样的分界，一个是描述电路本身（Verilog 等），一个是描述电路是
用来做什么（Simulink 等）并期望能够把这种描述变成可生产的电路。后者可以走得
很远，比如把 C (或者 Haskell) 程序直接编译到 FPGA。
【在 w***g 的大作中提到】
: VHDL和verilog只是描述电路连线的啊。你说的这个是simulation的功能吧？
: 用haskell写完电路描述后用runtime对它做simulation，我觉得应该没问题。
|
w***g
发帖数: 5958 | 66 我一直没有意识到后者的存在。再一想，理论上似乎也是可行的。长见识了。
【在 a*****e 的大作中提到】
: 这个领域的确有这样的分界，一个是描述电路本身（Verilog 等），一个是描述电路是
: 用来做什么（Simulink 等）并期望能够把这种描述变成可生产的电路。后者可以走得
: 很远，比如把 C (或者 Haskell) 程序直接编译到 FPGA。
|
