3 ms·

Here's my dream config language: * start with JSON * add comments (obviously) * allow trailing commas (obviously) * allow left-side and right-side to be ind

Here's my dream config language: * start with JSON * add comments (obviously) * allow trailing commas (obviously) * allow left-side and right-side to be independently and explicitly typed * extensible type support (JSON's lack of u64 is absurd) For example the following are all equivalent: * "foo" : f32 = 13.37 * "bar" : f32 = "13.37" * "baz" : f32 = 0x4155eb85 : hex And extensibility to allow: * "ham" : u64 = 123456789123 I would also be inclined to allow explicit config file hierarchy by allowing: * configs can specify their base * configs can specify their child * must be acylic I've thought about implementing this myself. But I've never written a real lexer or parser. It's on my side-project TODO list.

heinrich5991 5y ago
JSON has integer types/literals AFAIK, it's just that the Javascript implementation doesn't support them.
- forrestthewoods 5y ago
  It has numeric literals. But all JSON number types are f64. Which is sufficient to represent every 32-bit integer, but it can not represent all 64-bit integers. For code that needs a 64-bit integer, which is quite a lot, you have to encode the integer in a string. Lack of 64-bit integer (either signed or unsigned) is a pretty common and well understood pain point when using JSON as an interchange format.
  - RedNifre 5y ago
    No, that's just how JavaScript reads them, because JavaScript only has float64. JSON itself allows arbitrary large decimal numbers, including uint64.
    - forrestthewoods 5y ago
      I suppose you're right that the formal JSON specification doesn't actual specify what a number actually is. Only that it's a sequence of digits. TIL. In practice, when you are using JSON as an interchange format between tools and systems it is exceptionally likely that you'll be constrained to 64-bit float as the underlying Number data type. Even if there is no JavaScript anywhere in your data pipeline. I have been burned by this repeatedly. For the record, I have never written a single line of JavaScript in my professional career. In any case, my dream format would separate storage type from encoding type and formalize implementation extensions.
SAI_Peregrinus 5y ago
You might like RON[1]. It's far from perfect (and far from complete), but seems nice so far. [1] https://github.com/ron-rs/ron https://github.com/ron-rs/ron
amai 5y ago
https://json5.org/ https://json5.org/ maybe?

heinrich5991 5y ago

JSON has integer types/literals AFAIK, it's just that the Javascript implementation doesn't support them.

forrestthewoods 5y ago
It has numeric literals. But all JSON number types are f64. Which is sufficient to represent every 32-bit integer, but it can not represent all 64-bit integers. For code that needs a 64-bit integer, which is quite a lot, you have to encode the integer in a string. Lack of 64-bit integer (either signed or unsigned) is a pretty common and well understood pain point when using JSON as an interchange format.
- RedNifre 5y ago
  No, that's just how JavaScript reads them, because JavaScript only has float64. JSON itself allows arbitrary large decimal numbers, including uint64.
  - forrestthewoods 5y ago
    I suppose you're right that the formal JSON specification doesn't actual specify what a number actually is. Only that it's a sequence of digits. TIL. In practice, when you are using JSON as an interchange format between tools and systems it is exceptionally likely that you'll be constrained to 64-bit float as the underlying Number data type. Even if there is no JavaScript anywhere in your data pipeline. I have been burned by this repeatedly. For the record, I have never written a single line of JavaScript in my professional career. In any case, my dream format would separate storage type from encoding type and formalize implementation extensions.

SAI_Peregrinus 5y ago

You might like RON[1]. It's far from perfect (and far from complete), but seems nice so far. [1] https://github.com/ron-rs/ron https://github.com/ron-rs/ron

amai 5y ago

https://json5.org/ https://json5.org/ maybe?