2024 Clojure 状态调查中分享您的想法!

欢迎!请查看关于页面以获取更多关于其运作方式的信息。

+2
语法和读取器

已知的不充分明确区域(https://clojure.org/reader#The Reader--Reader forms

  • 符号(和关键字)的描述没有提到当前由Clojure函数使用的基本字符,如<、>、=、$(用于Java内部类)、&(在宏中的&form和&env)、%(据称在edn规范中有效)
  • 关键字目前接受开头的数字字符,这与规范不符 - 参见CLJ-1286

参考文献

通过简要查看当前页面(指南:https://clojure.org/guides/weird_characters 和参考:https://clojure.org/reference/reader),似乎这些问题中的一些已经被解决,但并非全部。

我想知道这个提问和相关的Jira票据是否有过时,是否应该更新或关闭。

15 个答案

0

评论人:jafingerhut

Clojure读取器文档也没有提及以下符号作为有效构成字符。这里在EDN说明中,它们都被提作为有效的符号构成字符:https://github.com/edn-format/edn#symbols

美元符号 - 在Clojure/JVM中用于将Java子类名称与类名称分开,例如java.util.Map$Entry
百分号 - 不确定为什么这是edn规范的一部分。在Clojure中,它似乎只用于#()内的参数,如% %1 %&
&符号 - 如在宏定义中的&form和&env中
<=符号 - clojure.core/=和许多其他符号
小于符号 - clojure.core/< clojure.core/<=
大于符号 - clojure.core/> clojure.core/>=

我不知道Clojure和edn规范在这方面是否应该相同,但这似乎对于这个工单值得一提。

0

评论人:jafingerhut

Alex, Rich在2011年对CLJ-17的评论:“出于性能原因,此处不考虑运行时验证。cemerick的建议,即任意符号的支持将使它们有效,这个观点是正确的,但任意符号的支持是另一张票/想法。” 我不知道是否有任何票据提议增强Clojure以支持任意符号,例如通过以下语法

`

|空白和任意#$@)$~))@字符在这里|

`

你认为为支持符号和关键词中的任意字符创建一个增强票据是否合理?

0

评论人:alexmiller

当然。我对此进行了研究,作为特性表达式的一个分支,#|已经为这种潜在用途预留。然而,其中存在许多棘手的问题,我不认为这将很快实现 - 更有可能在需要推动某个其他原因时才会这样做。

0

评论人:bendlas

这是一个错误的票据,但任何考虑#|任意符号(或字符串)|的人,请考虑将该分隔符设置为可配置的,如同mime多部分。

0

评论人:jafingerhut

我已创建了一个设计页面。我确信它没有列出您找到的许多复杂问题。如果您愿意分享任何笔记,我很乐意尝试记录这些问题。

http://dev.clojure.org/pages/viewpage.action?pageId=11862058

0

评论人:jafingerhut

Herwig,您能否编辑我在前一条评论中提到的设计页面,添加一个关于如何精确配置 mime multipart 分隔符的参考或示例,以及您为什么认为固定的分隔符不是一个好主意?

0

评论人:bendlas

我在设计页面上进行了评论。

0

评论人:alexmiller

删除了在阅读页面上已明确并不再是问题的几个问题。

0

评论者:bronsa

与 CLJ-1530 相关

0

评论者:adamfrey

相关内容:Clojure读取器不会接受包含相邻冒号的符号和关键字(参见(链接:https://github.com/clojure/clojure/commit/005ea1b5f96c5bb762e155032a865e29ad71bcf3#diff-3a5dca122734225f3f60263876401aebR275 文本:LispReader.java)),尽管当前EDN规范允许这么做。以下是有关相邻冒号的(链接:https://github.com/edn-format/edn/issues/68 文本:GitHub问题)的相关信息。我想要阐述为什么连续的冒号是不被允许的,并在Clojure_reader和EDN规范上进行同步。

0

评论人:bendlas

更新的读取器规范说明,一个符号可以包含一个/单独分隔命名空间。它还提到裸露的/是除法函数。
那么 clojure.core// 呢?这难道不是一个可读的符号吗?那么这是不是对“单/”规则的例外?
foo.bar// 也会可读吗?foo//bar会如何?

0

评论者:favila

我看到的另一个含糊之处是,不清楚关键字的第一条冒号是关键字(因此也是符号)的第一个字符,还是某种特殊字符,并且规范实际上描述了从第二个字符开始的操作。这很重要,因为关键字规范(在edn和读者规范中)是以与符号的差异来定义的。我认为许多奇怪的符号边缘情况(包括:1与:a/1的合法性)都源于这种含糊,不同的票据/补丁似乎选择了或选择了一个基本假设。参见(链接:http://dev.clojure.org/jira/browse/CLJS-677?focusedCommentId=35025&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-35025 文本:这篇评论)了解更多示例。

可能我们可以使用标记字面量来创建或打印当这些形式不可读时的情况,并以简化它们的字面量规范。例如,而不是生成复杂的解析规则来确保 clojure.core// 或 :1 是合法的,我们只需使字面量形式简单,用户在遇到这些边缘情况时写类似于 #sym(link: "clojure.core" "/") 或 #kyw "1"(打印这些)(并且打印器打印这些)。

0

评论人:alexmiller

我会说: (和::)是语法标记,规范描述了其后字符。但我同意,这会更明确。LispReader中的(错误)正则表达式也无助于此。

标记字面量概念是| |语法的有趣替代方案,后者已保留以支持未来对关键字和符号中的非法字符的可能支持。但我觉得这个想法超出了此票据的范围,这个票据的真正目的是澄清规范。

0

评论者:kunstmusik

晚些时候,我在用户邮件列表上提到

https://groups.google.com/forum/#!topic/clojure/CwZHu1Eszbk

1. 目前允许作为符号名称的一部分,例如

(let (link: a# 4 b#a 3) (println a1. b#a))

将输出 "4 3"。

  1. 也在自动生成符号中使用,并在 https://clojure.org/reference/reader#syntax-quote 中作为符号名称的一部分进行讨论。根据邮件列表的帖子,1. 被标记为“现在可能允许,但今后可能会改变”。我希望能更清楚地描述为一个特殊情况/保留情况,并请求将其在读取器中的使用限制,以防止用户现在使用它并可能导致以后代码出现故障。
0
参考: https://clojure.atlassian.net/browse/CLJ-1527(由 bendlas 报告)
...