可读关键字验证

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 可以在发出非可读关键字时在 print-readably 中增加 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报告）