java fluent api_Fluent API -- 现代DSL

论文导读系列(I)

Formal Language Recognition with the Java Type Checker[2016]

为什么Fluent API?

我们为什么需要DSL(领域特化语言)？

从个人观点来看 是为了更精简地表达

人们喜欢函数式语言的原因也是一样的

在函数式编程里杜绝所有的状态变化

是为了从交互式编程(Imperative programming)转向指令式编程(Declarative programming)

从而实现更精简的表达

可是世界上无数的系统 无数的领域

难道每个都实现自己的一套语言吗？

我觉得这是难以接受的

虽然现在想实现一个语言已经很方便了

只要提供一个BNF就会有工具帮我们实现自动机

可是不可否认这个过程门槛仍然是很高的

Fluent API是什么？

以防有人不知道我在这里简单描述一下

它就是能够串起来调用的一些函数，比如a().b().c()...

但是这里需要明确一点，Java的StringBuilder不属于Fluent API

因为它返回的永远是同一个对象，意味着所有的调用都发生在这个对象上

而Fluent API每个函数的返回类型都是任意的

StringBuilder这种调用方式被称为method chaining

Fluent API != Method Chaining

Fluent API将变量声明给省略了

这就是它的威力所在

极大地提高了语言的表达能力(精简性)

函数式语言不就是想要这个效果么？

也许聪明的你已经意识到

Fluent API是不是可以代替DSL呢？

事实上Fluent API就是DSL

但它是被嵌到宿主语言(实现语言)上的DSL

所以被称为EDSL(Embed DSL)

Fluent API就是DSL

似乎人们最近几年才理解到这一点

因为它拥有跟DSL同等的表达力

还能够用宿主语言的特性

它的性质决定了Fluent API今后一定会大火

为什么要类型检查？

原因是:

从经验上判断，对Fluent API进行类型检查是可行的

既然类型检查可行，我们就希望在编译时检查出问题减少运行时出现错误的几率

怎么写一个支持类型检查的Fluent API?

这里引入一个Box系统作为例子:

盒子支持两种操作,close & open

这也是最简单的一个DSL

现在我们来给它编码以支持类型检查

interface Box{

open(): Box;

close(): Box;

}

class TheBox implements Box{

open(){

return this;

}

close(){

return this;

}

}

new TheBox().close().open().close()

注意这里的open和close返回的是一个Box，以支持Fluent API

这样算是实现了类型检查吗？

当然 至少保证了Box类型不能调用explode函数

然后问题就暴露出来了:

众所周知，一个打开的盒子不能再打开，一个关闭的盒子不能再关闭

也就是说: box.open().open() or box.close().open() 都是不合法的

怎么写一个语义正确的支持类型检查的Fluent API?

Box类型其实应该细分为OpenBox和CloseBox

上个自己画的图, 这是一个自动机(伪), 由图可知，函数close, open，实际上是partial function:

这种内部实际上拥有复杂状态的类型叫做stated-type

与此相对的举个例子就是Java的StringBuilder，就不细说了

下面是实现:

class CloseBox implements Box{

open(){

return new OpenBox();

}

close(): never{

throw "No I should not call this method"

}

}

class OpenBox implements Box{

open(): never{

throw "No I should not call this method"

}

close(): CloseBox{

return new CloseBox();

}

}

new OpenBox().open() // I want the type checker to report an error.

当我调用OpenBox的open方法的时候, 最理想的情况是编译器能报一个错误:

但是我发现typescript好像没办法做到这件事情 让我十分苦恼

我在stackoverflow上问了这个问题Can typescript define uncallable method in a class?

论文中用的是java，作者用了一点trick去实现了这件事情但是可读性贼差

我认为语言完全应该实现这个feature

比如我返回never类型那么类型系统就不应该让我调用这个方法

我也在typescript的github项目上提了个issue

这里我直接throw一个error，让我们的脑内编译器抛出一个错误吧

这就是一个语义正确的支持类型检查的Fluent API的实现

自动化Fluent API生成

上下文无关文法是可以描述stated-type的

比如我们给Box系统提供一个BNF, 他会是这个样子:

// epsilon是希腊字母那个, 代表空

Box := open close Box | epsilon

在Box这个语言里 open open 这样一个语句是不合法的

没办法通过编译

换个角度， stated-type实际上是一个语义问题

我们能从BNF手动写出一个 语义正确的提供类型检查的Fluent API

然后我们思考，从BNF中识别出stated-type的规律是什么?

如果发现了这个规律，不单只手写API的效率大幅提高，不用动脑子

我们甚至能够 自动生成Fluent API

然后就是论文的精髓所在了

识别语义？这不就是下推自动机的工作么？

下推自动机有一个栈

这个栈的本质其实就是语义

只有在当前栈(语义)状态下，才能够调用sigma方法

这就是: 通过对下推自动机的模仿(mimic)实现语义类型系统

然后按部就班将自动机翻译成Fluent API就好了

这就是自动化Fluent API的生成逻辑

总结

Fluent API🐂🍺