Toml: Allow hexadecimal, binary and octal integer representations

[amadawn]

In many areas (such as science and engineering) integer configuration values are very common. Having TOML support them would make the format a little more general and less web-centric.

[pygy]

I suppose that you mean that you want hex, octal and binary integer literals supported?

0xf00, 0o6020, 0b101

[amadawn]

Yes, of course. The issue title was wrong. I just updated it.

[tnm]

I completely see the motivation, but I philosophically I think we want the spec to encourage just single way of representing numbers. Conversions in numeric representation are pretty easy/built-in in most programming languages, so it's not too burdensome on applications or implementors to offer this independently, if necessary.

[amadawn]

@tnm I strongly disagree. Leaving it to the application defeats the purpose of having a generic configuration file format as TOML. It means that numbers will always be decimal, because the alternative is for them to be strings (if you want to add the "0x", "0b" or"0o" marker).

[lawrencepit]

I have no use cases for octal and binary representations, but I can understand wanting to express values in hex. For example:

[colors]
  error = 0xff0000
  warning = 0xffff0

seems more natural / obvious / readable to me than:

[colors]
  error = 16711680
  warning = 16776960

on the other hand, I think in this use case you might go for CSS syntax:

[colors]
  error = "#f00"
  warning = "#ff0"

Perhaps the same goes for any hex, octal and binary values: always assign them as string value, and leave it to the application reading the config to interpret the values. But then you might as well say this for all types: why have types in TOML at all (i.e. everything is a string) ?

[amadawn]

@lawrencepit Actually you made an excellent point that I had in mind but which I didn't make. Why does TOML support types? It must be to make it easier to express common configurations (e.g. numbers, lists). Then, why should TOML support a single number representation, when there are several general and wide spread representations that people commonly want to use, such as hex, binary and octal?

[noct]

@tnm (sorry @tml :) I believe the issue being raised here is that the lack of support for varied integer literals could result in a multitude of ways to represent what really are just integers: "#ff0", "0xff0", or implicit "ff0", subverting the simplicity of the spec.

At least consider support for hex; it's doubly useful as a common color format in addition to binary representation.

[tml]

@noct I think you probably meant @tnm :)

[steakknife]

Hello, late to the party but I would like to use TOML to extract default configuration out of code (where it does not belong). As such, a sufficient ability to represent basic types is desirable.

To the issue at hand:

The problem of conventional constants (eg C style) is that they vastly complicate parsers, which defeats the purpose of TOML. (Please refer to any of the various syntax highlighters for C if you are unfamiliar with the worst kind of non-CFGs.)

Easy-to-parse literal integer constants:

o007
b1010

[88Alex]

:+1:

[jprichardson]

I support adding hex. The other two may just add more complication to the standard.

[BurntSushi]

I'm inclined to let this one pass and recommend just using strings instead. e.g., For colors, strings work better, since short hands like "#000" are usually supported.

However, I don't feel terribly strongly about this and there does seem to be a lot of support for it. I'm pretty solidly against a straight binary representation (really?) but could see octal (e.g., 0755) or hex (e.g., 0xA) being added.

I think I need to request a ruling from @mojombo.

[jprichardson]

I can see the case for octal. But at that point, might as well include binary as well, as developers will wonder why it's not included. Then we're at the point of parser creators including even more functionality.

In the interest of moving this standard forward and keeping simplicity, my vote goes to just drop 'em altogether and encourage strings for people who want this functionality.

[mojombo]

I'd prefer to pass on this as well, at least for now. We should continue to fight hard to keep TOML as minimal as possible while still solving the common problems. Strings will serve nicely for various representations of numeric data while we determine if this is a case of YAGNI or not.

[BurntSushi]

Great, sounds good to me.

[tshepang]

I am surprised that these aren't supported. We use JSON a lot at work, and I hate the standard for not supporting hex. We modified the JSON parser to accept that, which makes it not-JSON, but very very useful. We do some low-level bit-twiddling, and it really helps to see some stuff expressed in hex... decimal is serious incovenient at times.

I see some people talking about keeping TOML simple, but after reading the spec, there's stuff already far more complex than 0b 0o 0x (e.g. dates and compact tables). The workaround of using strings is just too much of a hack.

So, please... give us the good stuff.

[ChristianSi]

I can see that hex integers can be useful for various applications, but I wonder about octal and binary representations. Are there really any serious real-life use cases where they are more useful than their decimal or hex equivalents?

[tshepang]

I don't know. Selfish me is only interested in hex, but it really doesn't
hurt adding support for the other two.
On Apr 10, 2015 12:25 PM, "Christian Siefkes" [email protected]
wrote:

I can see that hex integers can be useful for various applications, but I
wonder about octal and binary representations. Are there really any serious
real-life use cases where they are more useful than their decimal or hex
equivalents?

—
Reply to this email directly or view it on GitHub
https://github.com/toml-lang/toml/issues/53#issuecomment-91508165.

[ChristianSi]

@tshepang: I think it does hurt adding features that aren't used, or that are used were rarely. Every new feature means a higher burden for all the implementors of the TOML language, so it's good to apply very strict "is still really needed?" checks before anything new goes in.

[tshepang]

let's just do hex then, since it's the most popular non-decimal format

[majewsky]

I would like to have these included as well, because of the specific domains where base-10 is strongly confusing. My strongest concern would be confusion to people not knowing about these special cases (C programmers not knowing octal notation might be confused that 0700 is not seven-hundred), but that can be easily relegated by using the proposed notations of 0x123, 0o123, 0b101.

[abrander]

Octal would be extremely useful for the os.FileMode type. Using base10 is a pain.

[rmunn]

If octal is included, PLEASE don't repeat C's mistake of having a leading 0 specify octal. To specify octal 755 file permissions, 0o755 should be used instead of 0755, for consistency with hex and binary.

But I'm strongly :+1: on allowing hex and octal (via 0x and 0o syntax), as both are highly useful in configuration files (hex for flags, and octal for file permissions). And once you've specified 0x for hex and 0o for octal, there's no real reason not to include 0b for binary, as it would feel strange not to have binary if hex and octal are available.

Allowing 0x and 0o (and 0b) would not greatly complicate implementation, as most languages offer ways to parse those representations (and if they don't, writing a parser for them is not hard).

I would be :-1: on allowing hexadecimal representations of floating-point values, but there are many cases when octal or hex representation of numbers is clearer than decimal.