请在 2024 Clojure 状况调查! 分享您的想法。

欢迎!请参阅 关于 页面获取更多关于此页面的信息。

+2
语法和读取器

未明确指定的已知区域(https://clojure.org/reader#The Reader--Reader forms

  • 符号(和关键字)描述未提及 Clojure 函数当前使用的组成部分字符,例如 <、>、=、$(用于 Java 内部类)、&(宏中的 &form 和 &env)、%(edn 规范中规定为有效)
  • 关键字目前接受开头的数字字符,这与规范相矛盾 - 参见 CLJ-1286

参考

Noah
通过粗略查看当前页面(指南: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 %&这样的参数。
Ampersand (和号) - 例如宏定义中的 &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

错误的工单,但任何考虑使用#|任意符号(或字符串)|的人请考虑使之定界符可配置,就像multipart mime一样。

0

评论作者:jafingerhut

我已经创建了一个设计页面。我相信它并没有列出您发现的大多数棘手的问题。如果您愿意分享任何笔记,我很乐意尝试记录这些问题。

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

0

评论作者:jafingerhut

Herwig,你能编辑我前一个评论中链接的设计页面,添加一个关于如何配置mime多部分分界符的参考或示例,以及为什么你认为固定的分界符是个坏主意吗?

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 issue)。我想解释为什么连续冒号不被允许,并在这个问题上同步Clojure Reader和EDN规范。

0

评论者:bendlas

更新后的阅读器规范说明,一个符号可以包含单个斜线“/”来分隔命名空间。它还提到裸斜线“/”表示除法函数。
那么clojure.core//的情况呢?这仍然应该是一个可读的符号吧?那么这是否是“单斜线”规则的例外呢?
foo.bar//也会是可读的吗?foo//bar又如何呢?

0

评论者:favila

我注意到另一个产生歧义的原因是,关键字的第一部分冒号是关键字的第一个字符(因此也是符号的第一个字符),还是它具有特殊性质,规范实际上是从第二个字符开始的。这是很重要的,因为关键字的规范(在edn和阅读器规范中)是以与符号的不同为条件的。我认为许多奇怪的边-case(包括: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/或#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. 可能现在允许使用,但以后可能有所改变。我希望将其更清晰地描述为特殊案例/保留,并请求将其在reader中的使用限制,以防止用户现在使用它,并可能在未来代码中出现问题。
0
by
参考: https://clojure.atlassian.net/browse/CLJ-1527 (由 bendlas 报告)
...