这是「从函数式角度看设计模式」的第二篇。目的是从和OOP不同的角度重新审视设计模式。 这里讨论的是观察者模式，和它在函数式语言里的等价品，模式匹配（Pattern Matching）。最后也会讨论到GADT（广义代数数据类型）。 Java的模式匹配 考虑一个可以容纳各种数据类型的列表，这里用的是Java语言。 123456public record Empty() {}var

最近在实习，主要的内容是Unity（WebGL），需求是能够从服务器（Proxy）获取数据后展示出来，应该是个蛮简单的任务吧。 Unity提供了一个叫UnityWebRequest的工具类，封装了常用的网络方法。按理来说使用Get方法就能够很容易得到结果了，但是官网没有怎么await长时间请求的案例，网上抄来的其他代码也不管用。 后来发现问题出在不应该用下载过程中的UnityWebRequest.

这是「从函数式角度看设计模式」的第一篇。目的是从和OOP不同的角度重新审视设计模式。 第一篇就从lambda说起了，因为这是函数式编程里面最常见的概念。在设计模式里，这个概念一般叫做「策略模式」。 按照定义，「策略模式是一种行为设计模式， 它能让你定义一系列算法， 并将每种算法分别放入独立的类中， 以使算法的对象能够相互替换」。简而言之，就是不把算法写死，而是在运行时可以按需切换。一般来说，OOP

在上次笔记后又过了一段时间，在 parser 方面并没有太多的进展。倒是在反复测试后发现或许 MonadError、MonadState 和 catchError 的办法能够提供我想要的组合子的语义。也为此做了一些简单的测试。 当然了，也有缺点：在有些语法分支上，是不得不使用 try 组合子的。而一旦启用了这个组合子，就又会不得不处理回溯的问题。 不过相比另一个问题，这个问题算是比较好解决的了。那

这篇文章讲一些相比前几篇比较无关紧要的细节，算是写Parser/Lexer时候的踩坑的记录吧。之后遇到了更多的坑，也会写在这篇文章里。 主要的一个大坑就是例如val a = sum<int>(3 + 4) 或者val b = foo<int, char>(...) 这里面用尖括号包起来的泛型类型标记，起初试验了许多不同的办法，也一度想过放弃，不过最后还是获得了相对比较令人满

写完了Lexer（其实没有），就可以开始准备写Parser了。为了方便调试，首先用ANTLR的语法来写，这样就可以在IDEA里面使用插件来实时调试语法的正确性。 不过，ANTLR的语法属于EBNF等价的，需要首先转化为BNF语法，这样才可以进行消除左递归和提取左公因子等操作转化为LL(1)文法。 之所以要转化为LL(1)的原因，还是跟Parser Combinator的缺陷有关。实际上，作为一种递

这是第三篇文章，打算简单介绍一下Lexer的概念。跟之前的篇幅不同，这部分内容就完全是自己瞎弄出来的了。 不保证正确性但是应该也可以作为一种思路吧。 之前也提到过用token组合子来在Parsing过程中进行Tokenization的操作，如果遇到了注释，就会出现问题。像是//这样的注释，会从注释的起始位置一直延伸到行末，又比如/* ... */这样的注释需要一直延伸到*/为止，但是针对单个字符

之前一直在用的Diaspora主题，其实算是随便找了个主题，还是有许多地方感觉受到了限制，比如说不支持页尾脚注，也没有自定义页面样式或者是友情页面模板这样的事情。 这次就换成了Fluid，总体来说可以保持和之前一致的风格，页尾脚注和友情页面都有了，还是挺满意的。 这个主题还支持LaTeX和Mermaid，不过虽然现在暂时用不到就是了。 主题是在这里找到的：https://github.com/fl

这是第二篇文章。这篇文章试图介绍一下Monadic Parsing的基本概念。 主要的内容来自于Programming in Haskell，虽然也加上了一些自己的个人理解。 提到编译器，就不可避免的要提到Parser了。那么，什么是Parser呢？ 抽象而言，Parser是一种输入字符串输出树状的数据结构的程序。一段含有特定的结构的文本（某个语言里面的程序的代码）被解析后生成对应的抽象语法树（

可能会是一个关于如何用monadic parsing来手写编译器的系列，来记录自己做实现的时候遇到的坑和一些经验。 第一篇文章会简单介绍一下一些基础设定。 首先是Monad。 众所周知，自函子范畴上的……（拖走暴打 好吧，这里不讨论学术上的定义，只试着以纯粹的使用者的角度从OO的视角出发去理解一下Monad，当然还有Functor，Applicative和Alternative这些typeclas