超市买菜

几天前,有个人来找我,问我:‘我这语言语法设计得怎么样?’

我连语法都没看,就问:‘你这语言的设计目的是什么?’

'我希望设计一个语言,融合FP跟OOP,这样我可以既有FP的表达力,也有OOP的易用性'

我忍着吐槽的欲望,问:‘那你有继承吧?’

‘有’

‘那Subtyping呢?’

‘当然也有’

‘那你打算怎么做类型推导?’

‘Algorithm W’

‘你该知道,Algorithm W是靠unification做推导的,你如果有subtyping,跟Algorithm W不相容,你想好这么解了吗?’

‘啊。。没有’

其实如果答出来,还有很多相近的设计问题:

  • OOP提倡extensibility,但是FP的ADT是封闭的,无法扩展新类型 - 而Class/Object无法在类型安全且不更改以前代码的前提下扩展新的method,这个语言该怎么提高扩展性?
  • Invariant/Covariant/Contravariant/Recursive Type/Existential Universal Quantification/Module的Subtyping怎么做?
  • Ad Hoc Polymorphism呢?如果靠Typeclass,这套东西怎么跟OOP的Class System整合?如果靠implicit Coherent问题怎么解决?

这些问题不是不能解,毕竟融合FP跟OOP的语言一大推,OCaml跟Scala不说,往早说,Luca的一推paper全是这个套路,但是问题是,当你要设计语言的时候,这些东西要先考虑清楚,而不是先去考虑语法。比如说Subtyping可以看F<:跟MLSub,Extensibility可以看MLPolyR/Data a la carte/Object Algebra。

另一个我想吐槽的事情,就是‘超市买菜’模型。很多人在设计语言的时候,都会有如下的思路:‘X是好的,Y是好的,Z是好的,我也刚好都需要,所以我这个语言要有X, Y, Z。’,比如上面那个人,就认为‘FP是好的,OOP是好的,我都需要,于是我去设计语法去了’

这样做的问题是完全没考虑到各种feature之间的互相影响-而这才是设计语言最麻烦的地方。

比如说,某个语言是Dynamically Typed的,但是有个叫Type Stability的概念:如果我能静态用Dataflow Analysis分析出类型,我就会用Type Directed Compilation做传统静态类型的优化。同时,我提供Type Annotation,所以如果分析不出来还可以手动加类型。

那好,这语言有Reference(指针),这再加上Higher Order Function,跟Dataflow Analysis很合不来,随便写点高阶的东西推不出,性能突然暴死怎么办?而Type Annotation则因为这个语言有Subtyping,同时Type Annotation选择会runtime check/convert的原因,导致没有Arrow Type,所以无法给高阶函数加Annotation,而这又恰巧是最需要的时候。。(Gradual Typing性能坑,而且他们还有Union Type,这下不止性能有问题,连做都不好做,见The root cause of blame: contracts for intersection and union types

IMO,如果设计语言,应该正好反过来:很多人都是先设计语法,然后再写实现,最后interaction管都不管听天由命的。如果是这个顺序:

  • 先去考虑我这个语言的目的是什么(提示:如果你不是GRAIL,Scratch,APL,那答案不会是‘语法’)(提示:答案九成是‘我在设计这个领域的DSL’。)
  • 然后去找可以实现目的的最小feature set-不可以被desugar的feature set越大,设计如上所说,越多坑,静态分析/类型推导/Partial Evaluation等操作也越难实现(要处理的case更多是一码事,不好处理的特性也是一码事(比如高阶语言不适合静态分析,指针不适合Partial Eval,Lambda Cube越往上爬越不好推类型,Subtyping更不好推等等))
  • 想想看自己要实现的Pass,脑袋里面建个大概的蓝图,想想要采用啥算法,看看有没有坑(要用Dataflow analysis做分析?跟高阶函数说再见吧。HM?Subtyping不相容。想在Effectful Language里面做Dead Code Elimination?你还是高阶的?好好想想Effect Analysis怎么设计吧)
  • 如果上一步发现冲突,移除一定的Feature/Pass,看看能不能被啥弥补,或者直接不要,然后接着找冲突
  • 好了,开始实现各种Pass吧
  • 到了最后,才到实现Surface Language/Concrete Syntax/Parser/Pretty Printing/IDE Support这些外观上的东西的地步。

那才可以在第零时间发现这些特性/Pass interact的坑,也可以有个明确的目的,而不是看到啥好的特性,就往语言里面乱塞,最后做出一个跟C++一样复杂坑多又不好扩展的语言。

编辑于 2019-05-20

文章被以下专栏收录