最近挤出些时间来看 Haskell 和 Functional Reactive Programming。由于主要工作领域和兴趣都是 user interface，所以就一知半解地写写用 FP 实现 UI 的想法。关于这方面入门者的困惑很多，我觉得有两个主要原因，第一是 FP 社区本身对 UI 领域投资不多；第二是比较熟悉 FP 的人谈及 UI 的时候必然会提到，而且往往只提到 FRP。这第二点让人产生传统的 model-view-controller 不适合 FP 的错觉。
Model-View-Controller Recap
谈论 FRP 前先回顾一下在我本人经历中占主导地位的传统 MVC 模式 [1]。这种模式中的 V 是 stateless view。从 model 发送到 view 的唯一通知是「model 发生了（详情不知的）改变」。Stateless view 可以天然的被看作 FP 意义上的函数，参数是 model，输出是整个或部分 UI 的 bitmap（或者说是 render 系统的 render command 序列）。
这个模式下的 controller 和 model 也都几乎可以看作函数。如果采用 FP 模式，model 不能是保存状态的「对象」[2]，而是变成一个 immutable 文档的列表。这样做并没有初看上去那么复杂：现代基于文档的 app 都要支持 undo/redo，所以如今的 model 已然无论如何要花力气实现文档列表（这个序列里的新文档通常是对旧文档进行 copy on write 得到，如果 FP compiler/runtime 实现得当应该可以达到同样效果）。
如上所述，我的最初感觉是传统 MVC 能够并不费力的和 FP 模式吻合，所以一再听到熟悉 FP 的人说 FRP 是 FP 在 UI 领域的主流甚至唯一解决方案让我有点惊讶，怀疑是否之前的想法过于简单化。
控件化 UI
上文谈到「传统 MVC」时所说的 view 其实和大多数人脑中的稍微有些不一样。很多 UI 是由现成的控件 (toolkit control) 组合而成。而传统 MVC 的 view 是指由 render 系统生成的一块 bitmap。举例来说，直接基于 Cocoa 和 MFC 的 NSView 和 CView 实现的 custom view 更符合 stateless view 的特性。如果你的 app 里没有 custom view，而是完全由 built-in control 组合而成，那么最外层的 container view 接受 model 之后的输出就不是 render command 序列，而是把整体的 model 分成不同部分来更新 inner view 的 model。在《MVC：用来打破的原则》的最后一节谈到了这种嵌套 MVC 结构。
控件化 UI 让很多程序员产生了一种「错觉」，就是 MVC 里的 view 的行为不是 render bitmap，而是把 model 的某部分同步到某个 property 上去。而 view 也变成了需要维护自身状态的对象。其实这只是看问题的角度不同。当你要自己实现足够复杂的 custom view，例如一个 editable canvas 时，仍然要回到基本的 stateless view 模式。经常写 custom view 的人处理大量 controls 的时候也把 controls 的更新看作 container view 的一种 render 行为而非数据的同步。
Functional Reactive
这时回来看 Functional Reactive Programming，它是更符合控件化 UI 的一种解决方案。FRP 所构建的 DAG 的末端和 control 相联的 event 或者 behavior 是和这个 control 自身的 model/proprty 的粒度直接对应。当整个 app 没有一个统一的 model 而仅仅用 controls 自身的 model 集合来维护所有状态的情况下，FRP 的 DAG 解决了这个 model 集合的同步问题，从而构建了一个 virtual global model。在传统 MVC 里经常提到 model 要负责 data integrity，DAG 正是实现这个任务的一个特定的形式化方法。
基于这个分析，可以总结关于 FRP 的三个结论。第一，FRP 解决了离散的 model 集合的同步问题，这只是 MVC 中 M 的部分。把 FRP 看作一个 UI 解决方案是忽略了 built-in control 所做的 render 工作。FRP 是一个 model 同步方案。
第二，可以通过在 app 中保持一个集中化的 model 来避免使用 FRP 的 DAG。集中化的 model 更符合传统的 MVC，从而也可以通过 stateless view 来采用 FP 模式。但这不代表构建集中化的 model 就一定是更好的做法。因为在控件化 UI 里强行采用 stateless view 模式意味着蛮力复制很多没有变化的数据。如果 FRP 的理论足够扎实，它的 DAG 似乎是更优雅的方法。而且即便真的采用了集中化的 model，仍然可以在内部采用类似 DAG 的方式来保证 data integrity。
第三，当 UI 中的某个 view 足够复杂而无法由 built-in control 来实现的时候，至少在这个部分必须回到传统的 MVC 模式。所以 FRP 和传统 MVC 实际是在 UI 实现里互相补充的两个部分。倾向于哪一个的决定往往更多地取决于系统性能等等非架构因素，而并非由系统的架构硬性决定，也不是和 programming paradigm 绑定的。
脚注：
- 关于这方面我写过几篇 blog（一，二，三）。
- 在《MVC：用来打破的原则》里说过，model 其实有「反对象」的特性。
技术奇异点 