design decision: rename "keyword" to "tag"

[tiye]

"keyword" 这个叫法, 我觉得是有歧义的. 在很多编程语言当中都有 keyword, 作为语言核心语法的标记, 被 parser/lexer 直接识别. Clojure 里的 keyword 跟这个功能显然是不一样的. Calcit 这边有个特殊的用法, 就是 (:: :quote $ defn) (:: %number-class 1) (:: :ok data) 这类的写法, 实际上以 "tagged union" 作为参考目标设计的, 这里 tag 扮演的角色称为 "tag" 就更自然, 而且中文的语境里"标签"用在 {:type :person, :name "Jon", :location :cloud} 当中也比起"关键字"更自然. 所以我决定稍微激进地进行调整.

另一个考虑是 tagged union 的场景也可能用 Symbol 作为标记, 这块我没想清楚, 但 Symbol 很多时候涉及到元编程当中的很多行为, 大量使用可能还有其他影响, 所以目前考虑还是 Tag 比较可行.

当 Tag 被大量使用以后, 结合之前对 Tuple 数据结构的扩展支持 1 到多个参数, Calcit 也计划转向更多使用 Tagged Union 来对程序进行更好的抽象. 虽然在动态类型语言当中模拟 Rust enum 或 Haskell sum type 仍然会存在很多问题, 但在一定程度上还是预期能够让概念稍微清晰一些. 不过, 这现在停留在思考阶段, 实际更改以后, Respo 等框架当中具体如何迁移, host data interop 问题如何处理和覆盖, 需要时间试验和确认.

计划短期会开始.

[tiye]

想了挺久觉得自己是把事情想简单了, Maybe a 在 Calcit 这个场景里还略复杂, 应该对应的是:

:: %maybe-class $ :: :some data
:: %maybe-class $ :: :none

我原先还以为一层的结构就能表示完了. 实际上复杂度就需要有两层.

而 Tag 抽象主要还是方便了这样一个场景:

key-match x
  (:some d) (println d)
  (:none) (println "|Nothing")
  _ (raise "|some error")

而且还有我比较关心的问题, 之前也算知道的, 比如经过 EDN 序列化的数据,

{}
  :a 1

跟运行时当中具备多态能力的数据,

{}
  :a $ :: %number-class 1

其中 %number-class 包含函数闭包, 这部分内容是不可能直接序列化发送到另一个进程里边去的. 这同时也意味着我想要代码始终保持动态类型的简单, 又想借鉴 Rust 把 Traits 玩起来, 其实是相互矛盾的一个事情. 所以我想的事情暂时还是不会有什么能满意的结果.

另外想要去掉 nil, 尝试了一阵还是没结果, 能破坏的代码太多了. 收不住的. 之前代码里对 Traits 结构过于简单的认识, 看起来也是埋着一些问题的.

[tiye]

现在提供的实现方式, 是对 tuple 的 class 用法做了调整, 调整了写法,

• (:: :tag data) 定义 Tuple, 携带一个默认的 %base-class, 这个 class 没有任何方法
• (%:: %class :tag data), 定义一个指定 %class 的 Tuple

然后增加了一个 &tuple:class 函数用于暴露 class 信息. 这个写法实际上就有点像 JavaScript 的 __proto__ 用法了, 一个隐式 prototype 引用, 不过 Calcit 这个 class 只是类似 Trait 的定义方法调用的写法, 没有更多功能, class 的组合能力也很弱.

这个调整对 Calcit 当前影响比较小, Respo 那边的代码稍微调整暂时也可以了. 后面观察再看看怎么优化.