可读关键字验证

Question

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

a) 在很多地方，程序化的关键字是完全有效的
b) 由于性能损失，不希望在构建过程中验证所有关键字

然而，有些创建关键字的场景，你期望它们在pr/read往返中是安全的，这时有一个更严格的关键字变体，会在无效的关键字上抛出错误，或者有一个谓词可以判断一个字符串是否是一个可读关键字会很有用。

Answer 1

评论者：pbwolf

1. 关键字通常在最终打印之前就准备好了。

2. 这种方法很少有问题，这种修复应该与问题成比例。

3. 无法阅读的关键字明确不是问题。问题在于pr和read。直接问题是pr在print-readably时静默失败打印为可读取格式。

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

1. 添加一个可读关键字的特殊谓词需要在后来调用pr时做出预测。我认为这样的预测通常是没有根据的，除非混淆了关心的事情。

2. pr可以在打印不可读取的关键字时增加irreadable-forms-printed。I/O本身就是昂贵的。

3. 如果pr/read有一天获得了 rounds-trip 功能，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报告）