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的readme中,它们都被列为有效的符号组成部分字符: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阅读器和EDN规范在这方面保持一致。

0

评论者:bendlas

更新后的阅读器规范表示,一个符号可以包含一个斜杠/来分隔名称空间。它还提到裸斜杠/是除法函数。
关于clojure.core//,它是否仍然应该是一个可读的符号呢?这难道不是“单个/”规则的例外吗?
foo.bar//也将是可读的吗?foo//bar呢?

0

评论人:favila

另一个让我感到困惑的地方是,不清楚关键词的第一个冒号是其本身还是关键词(以及符号)的第一个字符(或者它具有特殊意义,规格说明中实际描述的是第二个字符及其之后的情况)。这很重要,因为关键词的规格说明(在edn和reader规格说明中)是以与符号的差异来表示的。我认为许多奇怪的keywword边缘情况(包括: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. 这也用于auto-gensyms,并在https://clojure.org/ reference/reader#syntax-quote 中作为符号名称的一部分进行讨论。从邮件列表的主题来看,1.可能目前是允许的,但以后可能会改变。我会很高兴如果更清楚地将其描述为特殊情况/保留,并希望将其在reader中的使用限制在以防止用户现在使用它,并可能导致代码将来中断。
0
参考:https://clojure.atlassian.net/browse/CLJ-1527(由bendlas报告)
...