Welcome! Please see the About page for a little more info on how this works.

+17 votes
in Syntax and reader by
edited by

Just saw as part of Go 1.13 they added:

Digit separators: The digits of any number literal may now be separated (grouped) using underscores, such as in 1_000_000, 0b_1010_0110, or 3.1415_9265. An underscore may appear between any two digits or the literal prefix and the first digit.

And I thought that's a pretty neat feature. When writing big numbers, such as 92347683 it can be hard to read and parse mentally if this is million, billion, etc. Having a syntax for separation I think would be a nice addition to the reader. Doesn't have to be underscores, and might need some hammock time when considering all the valid Clojure number literal.

Thank You

4 Answers

+2 votes
by

If this existed when the Clojure reader was written, I think it's strongly likely that we would have supported it for parity. But now I think you have to weigh the added utility benefits (imo, quite small) with "update every reader/parser of Clojure tooling everywhere" and that is for sure a bunch of work across the ecosystem.

+1 vote
by

A case against this would be that it could affect search over code. Say you want to search for where in the code is the number 10000, you'd have to search for 10_100 as well, or maybe 100_00, etc.

Not sure this is a deal breaker, can't remember the last time I searched for a number in a code base, but still worth considering.

by
That's true of Java since Java 7 which added the underscore as separator, I believe:

https://docs.oracle.com/javase/7/docs/technotes/guides/language/underscores-literals.html
by
A similar argument against this which was brought up for adding raw strings, is that this could also complicate tooling, maybe for little benefits. Anything that makes parsing harder and with more edge cases basically can impact tools.
by
> it could affect search over code.

Tell it to ::namespaced/keyword syntax and namespaced maps. It is true that it makes number literals less greppable, but clojure is already not greppable at all.
0 votes
by
edited by

The rational seems to be making numbers easier to parse for humans, so to me this feel more like a feature in an editor and not the language

Adding such a change to the language makes the syntax for numbers more complex, doubling the work for all tooling to process correctly. So this would affect editors, LSP servers, format tools, linters, etc. So a change not limited to the Clojure reader.

And once added, code bases could easily become a mix of styles, adding to confusion and frustration, requing time for development teams and maintainers to decide which number format to use.

There are already editor features that display lambda functions and partials with fancy symbols.
Many editors also colourise Hex colour codes.
All of which does not require a change to the underlying langues

The benefit of having this as an editor feature is that it could be configurable as to what separator to use, e.g _ , . With comma and dot useful for currency values.

Without changing the underlying language, then the ability so search and use other text tolls remains unaffected.

I would prefer not to include this feature in the language and encourage those that find it useful to reach out to the maintainers of the editing tools they use.

by
> The rational seems to be making numbers easier to parse for humans, so to me this feel more like a feature in an editor and not the language

By pushing it to editors, you've now duplicated the work required by the number of editors people will use, in addition to making it inaccessible to reading the code in plaintext (such as in a patch or diff). By adding to the language itself, you completely bypass all of the additional work and provide a consistent and understandable format for all to benefit.

If we're voting (which I know we're not), I would vote in favor.
0 votes
by

In Emacs, you can try using this minor mode to highlight blocks of thousands with colors: https://emacs.stackexchange.com/a/59343

...