弱弱的问一问，DSL和模式匹配对于函数式编程很重要吗？

打算抽空学习函数式编程，在网上看了一些scheme的文章，来问几个初级问题。看到了一个对比函数式语言的文章（Scheme Erlang ML Haskell）：http://pierric-wu.blogspot.com/2007/09/zzwhat-is-really-differences-between.html

Scheme因为语法很抽象，所以在meta-programming方面很强，貌似DSL能力差不多就是指元编程吧。以前总看到某些文章说lisp很善于DSL，搞得都以为DSL和FP有很大的联系，现在看来不是这样。那个对比也指出，其他几种语言都有特定的适用领域，haskell就像一套数学系统。大家喜欢抽象语法还是特定语法呢。

好多FP语言都提到模式匹配，Haskell, ML, Erlang都是内置的，scheme是feature axises。那么Pattern-matching从概念上来说是不是很优雅很重要，scheme不原生支持它岂不是不够完美了。

DSL 是 show FP 计算核心力量的东西（简单就是力量），不是必要的。模式匹配，从概念上来说也不是很重要，但有总比没有好，至少可以少些几行代码。对于静态多态的函数式语言来说，模式匹配有其特殊的存在意义——类型构造器可以被当作算符来匹配，更显类型系统构造复杂系统的能力，比较重要。Scheme 无交叉类型，那个可有可无。

呵呵，楼上的对函数式编程很熟悉哦，你说的交叉类型是什么啊，指非正交吗。我想找本scheme的书看起，主要是因为这个语言最简单。我原来一直以为FP都是动态语言呢，haskell居然是静态类型的，还有类型检查。Haskell这个东西很特别的，要学深入函数编程，是不是很有必要学习一下haskell呢。

我开始发的那个网址是blogspot的，被封锁了，在办公室可以看，回来就看不到了。在另一个地方找到那个比较文章，把内容贴到这里算了。

---------------------------华丽的分割线----------------------------

(Assuming you mean Scheme for Lisp, since Common Lisp is a multiparadigm language that's as-much imperative or OO as functional...)


By strength:

Erlang: Distributed systems, massive concurrency, anything with lots of network IO (webservers, load balancers), particularly binary network protocols
ML: Fast. Easy to express complex data structures. Good for theorem provers, compilers, other algebraic manipulation software.
Haskell: Very strong compiler construction tools. Makes a pretty good scripting language (there's a thread about a Haskell shell on the mailing list right now). High reliability - I've found that 90% of the time my Haskell code "just works" the first time I compile it. Interesting research being done for webapps (WASH) and database integration (HaskellDB).
Scheme: Fun to make interpreters in. Very good for domain-specific languages. Good language-design research vehicle.


By language feature (excluding the obvious ones like first-class functions, and garbage collection):

Erlang: Pattern-matching, built-in concurrency & error handling, lightweight tuple/list/record syntax, symbol data type (called "atoms" in Erlang)
ML: Algebraic data types, pattern-matching, partial application, structure-based module system
Haskell: Algebraic data types, lazy evaluation, pattern-matching, partial-application, lots of syntactic sugar for data structures and common operations
Scheme: cons/car/cdr based, parenthesized syntax, macros.


By type system:

Erlang: dynamic
ML: Hindley-Milner type inference + (in Ocaml) objects and polymorphic variants
Haskell: Hindley-Milner type inference + typeclasses + existential types
Scheme: dynamic


Along the main language-feature axises:

Static/Dynamic: Haskell, ML - Erlang, Scheme
Pattern-matching/Cons-cells: Haskell, ML, Erlang - Scheme
Strict/Lazy: ML, Erlang, Scheme - Haskell
Pure/Impure: Haskell, Erlang - ML, Scheme (but Erlang lets you simulate mutable state through the process system)
Syntax/Parentheses: Haskell, Erlang, ML - Scheme
Practical/Research: Erlang - Haskell - ML, Scheme (Haskell started out as a research language but there's been lots of pressure lately to make it into a practical tool...for that matter, Ocaml is moving in that direction too).
Large/Small: Haskell, Ocaml - ML - Erlang, Scheme

把类型归结为dynamic和static就非常狭窄了,模式匹配也是一种类型系统.如果一个语言支持pattern matching那么就意味着他的类型系统是structural的.
比如说Haskell的类型系统就是static, strong, latent, structural typing, with nominal typing available via newtype and manifest typing through optional type declarations
而Erlang的类型系统则是dynamic, strong, latent, structural typing
Haskell的类型系统支持的很全,即可以方便你做pattern matching,又方便你做类似于java/c中的nominal typing.
而Erlang只支持structural,那么做nominal typing的时候就比较麻烦，比如Erlang里面那个臭名昭著的record语法,就是因为没有nominal typing的结果.

从语法角度说，scheme的语法最直接。在编译器内，一段程序就是一个树，abstract syntax tree。各种千奇百怪的语法，说到底，就是想办法用字符串来描述一棵树。括号和缩进格式，诸如begin... end，｛｝，都是计算机语言中常用的描述树层次结构的方法。而Lisp/Scheme 的语法干脆就直接用嵌套列表来表示语法树。所以你看各种书里，在介绍secheme求值时，parser几乎都不提。因为她的语法本身就是一棵树，用list描述的树，而原本parser的工作就是将token list转换成syntax tree。

在meta-programming中，要让一种语言可以方便的处理用自身写的程序。这方面，lisp/scheme的语法优势就显现出来了---程序是list，而语言(list Processor)就是用来处理list的。对我来说，scheme这种语言吸引人的地方就是，她是很小的语言核心+Macro扩展机制。Macro就是一段程序，把一棵语法树(list)转换成另一棵(list)。现代的scheme macro就是用模式匹配的方式来制定转换规则。另外，PLT-Scheme中有一个match library，通过Macro扩展来提供pattern match的功能。

上次看到一篇讲类型系统的短文，写的挺不错的,我刚好简要的翻译了一下，lz可以看下：

http://simohayha.iteye.com/blog/151653

Subtyping和Subclassing是不一样的.Subtyping不一定是Subclassing,反过来SubClassing也不一定是Subtyping.在Java里面，implements是subtyping，extends是subclassing兼subtyping.

那个类型系统，scheme和erlang像，haskell和ocaml像，如果要学习两种，各挑出一种比较有代表性吧。。。



那个macro，不是r5rs里面才引进的么，叫什么“卫生宏”，看了一个英文文章讲述common lisp和scheme的macro系统的区别，硬是看不明白，英文水平太差了，只知道作者的意思是CL的宏实用一些。

除了SICP，市面上都买不到什么scheme的书，都说SICP比较难，自学的话最好有一点scheme/lisp基础。目前只有 The Scheme Programming Language, Third Edition 和 Teach Yourself Scheme in Fixnum Days 的电子书，好多人提到的“little scheme”，不知道哪里下得到。

SICP本就不是一本教授语言的书,真正关于语言的前前后后加起来内容连一章都不到.

当macro展开时会在当前的scope里引入新的symbol，而这些新引入的symbol会和原有的symbol同名，所谓capturing problem。而这种错误，因为在展开macro时产生的，所以程序员光看源代码很难察觉。

比如，你定义一个macro or如下

(or e1e2) ---> (let ((v e1)) (if v v e2))

如果你的程序这样写 (or nil v)， 展开后就是：

(or nil v) ---> (let ((v nil)) (if v v v))

原来“(or nil v)”中的v是free variable，但展开后就和macro中的binding variable v同名，成了bound variable。

早先的解决办法，只是展开macro时，把所有新的symbol都“篡改”一下，好比 v 改成 v0340。但这样只是减少了重名的可能，显然没有彻底解决问题，"不卫生"也。Hygienic macro(卫生宏)就是指不会产生这种capturing problem的宏展开机制。具体方法，感兴趣可以读 Hygienic Macro Expansion 这篇文章。



你读SICP的难度，和你对scheme/lisp语言熟悉与否没什么关系。反过来，到应该说你不理解SICP的内容，就谈不上有scheme/lisp的基础。Scheme语言本身并不难，就是list + lambda calculus。需要花时间的是理解、熟悉functional programming的思考方式，这些是SICP中教的。另外，就学scheme来说，你提到的那些书（The Scheme Programming Language, Third Edition等）都是不错的教材， 重要的还是Brian Kernighan那句老话，"The only way to learn a new programming language is by writing programs in it"