可读关键字验证

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. 当 pr 以生成不可读的关键字时，pr 可以递增 irreadable-forms-printed。I/O 本来就非常昂贵。

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

4. 相比之下，一个充斥着 "readable-keyword?" 谓词的程序将永远使我僵化——谓词检查可能也不再是必要的。

5. “可读关键词？” 是否符合读者的行为、读者文档、EDN 或者一些保守的常见子集？相关：CLJ-1527 "澄清并统一 Clojure（及 EDN）中有效符号和关键词的规则"，CLJ-1530 "使 foo/bar/baz 不可读"。

6. 每个规范编写者是否都会为是否将关键词指定为 "keyword?" 还是 "readable-keyword?" 而纠结 – 然后总是选择 "readable-keyword?" 以防万一有人以后决定序列化数据呢？... 这将使程序杂乱无章，并模糊了问题。

7. 谁会测试 不可读的打印格式？一个“道歉”，非解决方案的解决方案可能会变得相当复杂。

8. 也许治疗方法会弊大于利。为什么不改进 pr/read 呢：消除问题而不是添加特性来解决这个问题？

Answer 2

由 alexmiller 发表的评论

这里的问题特别关于由用户输入或其他不受您控制的数据（例如，来自 json 输入的任意键）创建的关键词。当您需要验证此属性时，您正在接受输入，将它们转换为关键词，然后稍后期望打印出该数据。我已就此与许多人讨论过，当人们询问它时，他们会知道他们处于这种情况。打印失败或报告远在以后是无用的。问题在于从一开始就避免创建不可互逆的数据（在此处不接受它或转义它）。

尽管如此，另一个可能的解决方案是添加一个用于字面符号和关键词的转义机制。我们以前在这方面做了一些设计工作，当时将它搁置起来，但这仍然是一个可能的选项。

这不是一个当前高优先级的问题，但我认为将此票据保留下来以捕获这个想法是有用的。

Answer 3

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