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

欢迎!有关如何工作的更多信息,请参阅关于页面。

+2
语法和读取器

已知的不明确区域(《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读取器文档也未提及以下符号作为有效组成字符。在这里的EDNREADME中都提到了它们是有效的符号组成字符: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 issue)是关于连续冒号的。我想澄清为什么连续冒号是不允许的,并让Clojure Reader和EDN规范在这方面保持一致。

0

评论者:bendlas

更新后的读取器规范表明,一个符号只能包含一个/来分隔命名空间。它还提到裸/是除法函数。
那么关于 clojure.core// 呢?这应该还是一个易读的符号吧?这是不是“单条斜杠/”规则的例外呢?
foo.bar// 是否也会是可读的?foo//bar又是如何呢?

0

评论人:favila

我还发现另一个歧义的来源是关键词开头的第一个冒号是否是关键词(和符号)的第一个字符,或者是某种特殊字符,而规范真正描述的是从第二个字符开始的。这很重要,因为关键词的规范(在_edn和reader规范中)是以与符号的差异来给出的。我认为许多边缘情况的关键词(包括: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
by
参考: https://clojure.atlassian.net/browse/CLJ-1527(由 bendlas 报告)
...