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添加了下划线作为分隔符,我认为是正确的。

https://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html
有关于此的相似论点是反对添加原始字符串的,即这可能也会使工具复杂化,可能带来一些小的利益。任何使解析变得更加困难并具有更多边缘情况的工具都可能受到影响。
>> 这可能影响到代码的搜索。

告诉它 ::namespaced/keyword语法和namespaced maps。确实,这会使数字字面量更不容易用grep搜索,但Clojure现在已经完全不被grep搜索了。
+1

如果Clojure读取器在那时存在,我认为我们很可能已经支持它以保持一致性。但现在我认为您需要权衡增加的实用性利益(我认为相当小)与“在整个Clojure工具套件中更新每一个读取器/解析器”的复杂工作,这肯定会跨生态系统进行大量工作。

0

编辑

理性来看,这似乎是为了让数字更易于人类解析,因此这更像是编辑器中的一个功能,而非语言本身。

将这样的改动加入语言将使数字的语法更复杂,加倍了所有工具正确处理所需的工作量。因此这将影响编辑器、LSP服务器、格式化工具、linters等,而不仅限于Clojure读取器。

一旦添加,代码库可能会轻易地混合不同的风格,增加混乱和挫折感,迫使开发团队和维护人员决定使用哪种数字格式。

已经有编辑器功能可以显示带有华丽符号的lambda函数和部分。
许多编辑器还支持彩色化十六进制颜色代码。
所有这些都不需要改变底层语言。

将此功能作为编辑器功能的好处在于,它可以配置要使用的分隔符,例如 _ 或 .,逗号和点非常适合货币值。

在不更改底层语言的情况下,搜索和使用其他文本工具的能力不受影响。

我倾向于不在此语言中包含此功能,并鼓励认为它有用的用户联系他们使用的编辑工具的维护者。

> 理性来看,这似乎是为了让数字更易于人类解析,因此这更像是编辑器中的一个功能,而非语言本身。

通过将其推向编辑器,你现在需要为人们使用的每个编辑器重复所需的工作量,同时还使得在纯文本(如补丁或diff)中阅读代码变得难以访问。通过将修改加入语言本身,你完全绕过了所有额外的工作,并提供了一个一致且易于理解的格式,供所有人都受益。

如果我们投票(我知道我们不会),我会赞成。
0

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

...