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

欢迎!有关如何使用本网站的更多信息,请参阅 关于 页面。

+17
语法和读取器
编辑

刚刚看到 Go 1.13 中加入了一个功能

逗号分隔符:现在可以使用下划线在任何两个数字之间或不带的符号前和第一个数字之间(分组)分隔任何数字字面量,例如在 1_000_000、0b_1010_0110 或 3.1415_9265 中。下划线可以出现在这些位置之间。

我认为这是一个很酷的特性。在编写大数字时,例如 92347683,如果没有分隔符,那么在心中阅读和解析时可能很难确定它是百万、十亿等。为读者添加分隔符的语法将是一个很好的补充。这不需要是下划线,在考虑所有有效的 Clojure 数字字面量时可能需要一些时间。

感谢

4 个答案

+1

反对这一点的观点可能是,它可能影响代码的搜索。比如你想搜索代码中 10000 出现的位置,你将不得不搜索 10_100,或者 100_00 等。

不确定这是否是致命问题,我记得上一次在代码库中搜索数字是什么时候,但这仍值得考虑。

我认为这是自Java 7以来的事实,因为Java 7加入了下划线作为分隔符。

https://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html
反对这一点的论点之一,即在添加原始字符串时提出,这可能会使工具变得更复杂,可能好处不多。任何使解析更困难且具有更多边缘情况的事物基本上都会影响工具。
> 它可能会影响代码的搜索。

告诉它 ::namespaced/keyword 语法和命名空间映射。确实,这让数字字面量更不容易被 grep,但 clojure 本来就不容易被 grep。
+1

如果这个功能在 Clojure 读取器编写时存在,我认为我们很可能已经支持它以保持兼容性。但现在我认为您必须权衡增加的实用功能(据我所知,相当小)与“更新 Clojure 工具的全生态系统的每个读取器/解析器”的重要性,这确实是一大堆工作量。

0

编辑

这个特性似乎是为了使数字对于人类更容易解析,因此对我来说这更像是一个编辑器的特性,而不是语言本身的特性

将这样的更改添加到语言中会使数字的语法更加复杂,使得所有工具正确处理所需的工倍增。因此,这将影响编辑器、LSP服务器、格式化工具、代码检查器等。因此,这不是仅限于Clojure读取器的更改。

一旦添加,代码库可能会轻易地变成各种风格的混合,增加困惑和挫折,需要开发团队和维护人员花费时间决定使用哪种数字格式。

已经有编辑器特性可以显示带有花哨符号的Lambda函数和部分函数。
许多编辑器也会给十六进制颜色代码着色。
所有这些都无需更改底层语言。

将此作为编辑器功能的优点在于,它可以配置使用哪种分隔符,例如_,.。逗号和点对于货币值很有用。

不改变底层语言,那么搜索和使用其他文本工具的能力不受影响。

我更愿意不在语言中包含这个特性,并鼓励那些发现它有用的人联系他们使用的编辑器的维护人员。

> 这个特性似乎是为了使数字对于人类更容易解析,因此对我来说这更像是一个编辑器的特性,而不是语言本身的特性

通过将其推送到编辑器,你现在需要重复的工作量就是人们使用的编辑器数量,此外,它还使得在纯文本中读取代码(例如在一个补丁或diff中)变得难以访问。通过将添加到语言本身,您完全绕过了所有额外的工作,并为所有人提供了一个一致和可理解的格式。

如果我们是在投票(我知道我们不是),我会投票支持。
0
by

在 Emacs 中,您可以尝试使用这个小型模式以颜色突出显示千位的块: https://emacs.stackexchange.com/a/59343

...