深化多态用法的思考

[tiye]

#43 当中提供了一个简易的多态的模仿, 对已有代码没有修改.
不过这个结构不够通用, 打算进一步深化, 扩展到更多的场景, 以及更可靠的运行逻辑,
目前的思路:

• 增加原生的 CalcitTuple 类型, 代替 List 用于构造 :: Num 1 这种数据, 记为 :: Num 1
  先用 :: 这个符号表示 Tuple, 具体后续是否调整再看了.
• 解释器层面将 .m x y z 识别为内部函数, 用内部实现执行 .m.
  这里涉及 js codegen 当中的对应语法需要适当兼容.
• 原生的 Number, String...等等内置类型, 在 invoke 调用过程中自动加载内置 class,
  如果涉及到 CalcitTuple 本身, 就需要特殊处理.

其中 :: Num 1 整体被叫做 "instance", 其中 Num 叫做 "class", 强行参考 Haskell 了.
对应的, 内部需要对常用的类型进行一下处理, 提供内置类型的 class.

对 Macro 的影响

由于当前的方案是作为 proc 处理的, 暂时对 macro 系统没什么影响.

对 js codegen 的影响

主要是生成 js 需要改成动态的实现, 对性能有影响.
并且 js 实现, 类比 Rust runtime 中的内置 class, 也需要提供相应的 class.
为了已有的 js 实现, 可以考虑用 .!m x 来表示 x.m() 这种调用

具体实现和产生的影响

按照当前的实现, class 部分的变量定义检查相当于断开了.
比如 .m a 这个方法调用, 由于 a 的类型未知, 也就无法判断 .m 是否存在.
这样之后大范围的方法调用都是动态的代码, 无法在编译的时候简单判断.
未来尝试下是否有办法做局部的追踪, 目前没办法.

目前运行到 method 再调用的函数的位置, 处理是非常动态的,
Rust runtime 中是借助 runner 文件解释器实现去调用,
而 js 部分靠的时候 mutable reference 从运行时注入, 实现显得有些脏.
所以有部分逻辑目前需要人工维护保证正确性了.

还没有在 Respo 等场景当中进行检测..

其他

这个修改还挺大的, 目测没有大问题. 另外 class 和 instance 实现可能存在的性能问题暂时先次要考虑.

[tiye]

当前提供了一个可是试用的实现 #45 .

[tiye]

又改了一片, 主要是替换了一些方法... #53 .

有个特殊的地方要说明, 调整了一下之前的实现, 使用的时候从原来的,

; "Old semantics"
def Num $ %{} %Num
  :inc $ fn (x) $ :: Num (&+ x 1)
  :show $ fn (x) $ str x

改成了,

def Num $ %{} %Num
  :inc $ fn (x)
    update x 1 inc
  :show $ fn (x)
    str $ &tuple:nth x 1

其中传递的参数 x 原先用的是原始的 raw_value, 而不是 tuple, 现在会传入 tuple.
准确说是内置的类型用的还是原始的数据, 比如 number, string, list, map, 自定义的会带上 class 整个 tuple 传.
这样设计的目的, 是考虑复用的情况, 返回的 class 如果写死, 拿到其他 class 复用就成问题了.
而方法输入/输出带上 class 信息的话, 就可以适配不同的 class 使用了.
内容参考 https://www.well-typed.com/blog/2018/03/oop-in-haskell/ 当中模拟继承多态的用法.

相对应的, 这时候需要能够操作 tuple, 这里扩展了 assoc 和 nth.