这是「从函数式角度看设计模式」的第六篇。 之所以写这一篇，也是因为在最近几年乃至最近的项目实践里，感觉到了一些有趣的东西呢，这时候回想到之前学校里写项目的时候，会有人「去学习和使用Builder pattern来解决问题」。 那么故事先从Kotlin里面的一个神秘的类型开始： 123fun play(manager: AbstractManager, initializer: SimulatteB

最近遇到了一个有趣的小问题，在处理文字的时候遇到了需要处理HTML编码的情况。具体来说，是例如 、<、>这样的玩意，需要把它们变成人类可以理解的字符。 仔细查了一下，发现这个问题虽然在网上能搜到一大堆解法，但绝大部分的解法都让人难以满意，虽然最后还是找到了较满意的解法，但是也想想说不定值得把它们列举一下当一个参考了。 大体来说，最常见的解决方法有这么几

这次继续讨论递归下降算法吧。 上次提到的框架基本上就是递归下降的纯函数式编程的实现了，不过，缺点也很显然，首先就是太长，样板代码太多，可读性和可维护性差。上次倒是也提到了。 不过也不难发现，这里重复的模式和样板代码，做的东西基本就是一件事：在纯函数环境下（没有副作用和状态的场合），模拟出「可变状态和副作用」的效果。 比如那个二元组的第二项tokens列表的操作。 又比如逐层嵌套下去的if语句块。

最近重拾编程语言设计的事情，不可避免的又要遇到写parser的事情了。 想起来，三年前也做过类似的事情，不过那时候是用Haskell写parser combinator，有点知其然而不知其所以然的感觉吧。 这次重拾parser的话，为了能够让自己明白到底代码在干什么，也为了之后可以更好的维护和扩展语法吧，就选择了直接手写递归下降语法。当然，用的是Scala，也尽量保持了纯函数式的风格。不过，在写着

所以最近其实在做的小实验是试着在Java8里面实现简单的模式匹配功能。也许说是模式匹配更像是Kotlin的when语句吧。 主要因为近期比较多开发和维护基于Java或JS这种经典技术栈的存在代码，然后因为之前的开发者看得出来是写惯了Java8这种上古语言的，所以代码风格很古老，经常会写着写着就想，要是有个模式匹配就好了。 也觉得如果有模式匹配确实会很好玩吧，同时也算是为了实践自己「把Java当作一

最近在做一些Java上面的小试验，然后做到一半突然觉得，似乎可以把这个代码转化为一个target Java 8的库，然后就在想，是不是可以发布到Maven上面呢？这样的话，就可以在别的项目或者让其他人能够用到了呢。 另外一方面，这几年认识的朋友也都有发布过自己的仓库，所以也想试试呢。 于是首先第一步就是把原本的intelliJ生成的只有src的项目转化为符合Gradle文件结构的模样。 这一步大概

二月份没有做什么别的项目，主要的时间花在三门Coursera的课上了。确切的说，其实是同一门课：UW的Programming Language课。 这门课是华盛顿大学的CSE341课程的Coursera版本，根据官网的介绍，大概是「简要介绍了编程语言的基本概念，包括抽象（Abstraction mechanisms）、静态和动态类型、作用域、语法（Syntax）和语义（Semantics）、闭包（

最近在复习Kotlin的协程，偶然在这篇文章里遇到一道有趣的题目，也就稍微做了一下。 题目第一眼看起来还是挺有难度的，要在Kotlin里面实现Haskell那样的do-notation语法。不过，有了前一篇文章的提示，再加上一些Kotlin/Coroutine和函数式编程的基础，倒也不难做。大概的想法是用协程的挂起和恢复来模拟出Monad的组合。具体的细节就不展开了，有兴趣可以自己试试。显然，Op

上次提到使用SwiftUI和SwiftData时候的几个问题，后来也陆续解决了。 SwiftUI的「返回」导航 先说第一个关于SwiftUI的问题。 这里实际上我想做的大概是，在创建新数据的过程中，取消创建并且回到主页面。原本的实现是这样的： 123456Button { pathManager.path.removeLast(2)} label: { L