2024 年 Clojure 调查问卷 中分享您的想法!

欢迎!请查看 关于 页面以了解更多关于该方式的信息。

0
core.typed

我在一个项目中应用 core.typed 处理相当大的哈希表序列。我遇到了两个问题
1. 错误输出太大,无法由人类解释(每个错误 4k)
2. 报告的错误似乎是不正确的,因为预期类型和实际类型似乎匹配。

我通过编写一个比较预期类型和实际类型的函数得出这个结论。这个函数也包含了,可能是一个如何为大哈希表上的错误生产更紧凑和可读的输出的例子。

longOutput.clj 包含失败的函数(derive-sms_msg-fmt-fail ..)和几乎相似的成功函数(derive-sms_msg-fmt ..)(check-ns)。

该文件还包含函数(show-error),该函数打印出类型错误的一个副本,然后与预期类型分析推导类型。推导的类型是预期类型和一些基于包含可选键的派生类型的并集。所以我看到的并集是预期类型的子类型,报告的错误是不正确的。

在文件的 show-error.output 中包括了一个错误分析的例子。

3 个答案

0

评论者:cvkemenade

PS:我想象的当前(show-error ..)可以作为生成更紧凑的错误消息的基础(使用输出长度作为判断当前错误格式或差异分析结果哪种产生最紧凑错误报告的标准)。

PS:我强烈相信静态类型检查器的大优点。但就当前的错误消息而言,由于体积巨大的错误输出,几乎不可能迁移涉及大哈希表的项目。

0

评论人:ambrosebs

嗨,Cees,

感谢详细的报告,这很有帮助。我会进行调查。

0
参考: https://clojure.atlassian.net/browse/CTYP-102(由cvkemenade报告)
...