可读关键字验证

Question

一个常见的问题为什么可以编程式创建不能读取的关键字实例（https://clojure.org/guides/faq#unreadable_keywords）。

a) 在许多地方，程序性关键字是完全有效的
b) 由于性能影响，不希望在构建时验证所有关键字是不希望的

然而，存在一些创建你希望为pr/read往返安全的关键字的用例，在这种情况下，拥有一个更严格的、在无效关键字上抛出变体的keyword或有识别字符串是否为可读关键字的谓词会是很有用的。

Answer 1

评论由：pbwolf

1. 关键字往往在最终pr的远处准备。

2. 令人印象深刻的是，通过这种方式，偏差关键字很少成为问题。修复措施应该与问题相称。

3. 不可读关键字明确不是问题。问题是属于pr和read的。紧迫问题是pr在打印时静默失败，而print-readably。

3b. 这个pr/read问题可能是暂时的。

1. 添加一个特殊谓词来判断可读关键字的前提是你可以预测某人是否会稍后调用pr。我认为这样的预测通常是无根据的，而没有混淆关注。

2. 当在print-readably中生成不可读关键字时，pr可以增加irreadable-forms-printed。I/O无论如何都很昂贵。

3. 如果pr/read有朝一日获得了往返所有关键字的资源，pr仍然必须测试一个关键字以选择其输出格式。因此，今天安装的检查可以是第一步，而不是临时措施。

4. 相比之下，一个充斥着“readable-keyword?”谓词的程序将永远如此——并且谓词检查可能甚至不再必要。

5. “readable-keyword?”符合读者的行为，读者文档，EDN或某些保守的公共子集吗？相关：CLJ-1527 “澄清并统一Clojure（和EDN）有效符号和关键字规则”，CLJ-1530 “使foo/bar/baz不可读”。

6. 每个规范编写者会为将关键字指定为"keyword?"还是"readable-keyword?"而纠结——然后只是为了以防万一，最终总是选择"readable-keyword？"，以防有人将来决定序列化数据？因而使程序显得杂乱无章，模糊了关联问题的讨论。

7. 谁会测试irreadable-forms-printed？一个“道歉性”的非解决方案可能会很复杂。

8. 也许这种方法会比问题本身还要糟糕。为什么不改进pr/read呢？消除问题而不是添加功能来绕过它？

Answer 2

由：alexmiller评论

这里的问题尤其涉及由用户输入或其他控制之外的数据（例如来自json输入的任意关键字）创建的关键字。当你需要验证此属性时，你正在接受输入，将它们转换为关键字，然后后来期望打印这些数据。我与许多人讨论过这个问题，当人们询问时，他们都知道他们处于这种情况。在很远的将来打印失败或报告问题并不有帮助。问题是防止首先创建不可逆向转换的数据（并在那时拒绝或转义它）。

话虽如此，另一个可能的解决方案是添加字面符号和关键字的转义机制。我们过去已经做过一些这方面的设计工作，但当时将其搁置了，但这仍然是另一个可能的选项。

目前这不是一个高优先级的问题，但我认为将这个想法保留在这个票据上是有用的。

Answer 3

参考：https://clojure.atlassian.net/browse/CLJ-2309（由alexmiller报告）