Live data from Hacker News

TOML: Tom's Obvious Minimal Language

toml.io

121–130 of 229 posts

Re: TOML: Tom's Obvious Minimal Language

#122
post #10

JSON is basically perfect if it allowed trailing commas and comments. TOML is not a replacement for JSON because of how badly it chokes on nested lists of objects (being both hard to read and hard to write), due to a misguided attempt to avoid becoming JSON-like[1]. [1] https://github.com/toml-lang/toml/issues/516

haha, this exact thing is my biggest gripe with toml

edit: just found https://github.com/toml-lang/toml/discussions/915#discussion..., super happy to be able to rest this out early

Re: TOML: Tom's Obvious Minimal Language

#123
post #117

TOML is nice as a kind of extended .ini format but I don't like the approach to avoiding nested elements. I prefer KDL. It's like XML but with almost zero syntax. Probably not always the best idea because it's so niche but it's just really simple while having all the basics like comments and multiline strings.

KDL (assuming you mean https://kdl.dev/ ) looks great, thanks for mentioning it.

See also: https://sdlang.org/

Re: TOML: Tom's Obvious Minimal Language

#124
post #83

Earlier quoted context omitted.

> JSON is basically perfect if it allowed trailing commas and comments. I agree, especially in regards to the comments, because sometimes the data itself isn't enough and additional human-readable context can be really useful! In that regard, JSON5 is a wonderful idea, even if sadly it isn't widespread: https://json5.org/ It also supports the trailing commas and overall just feels like what JSON should be, to make it…

I like the idea of JSON5, but it allows a bit too much in my opinion. For example, why add the single quote? Why hexadecimal identifiers?

You might be interested to check out JSONC and JWCC/HuJSON

https://nigeltao.github.io/blog/2021/json-with-commas-commen... https://github.com/tailscale/hujson

Re: TOML: Tom's Obvious Minimal Language

#125
post #75
post #63

Earlier quoted context omitted.

> JSON is basically perfect Until you realize you can't actually store real integers because every number in js is a float...

JSON allows you to store arbitrarily large integers/floats. It's only in JS this is a problem, not if you use JSON in languages that support larger (than 54-bit) integers.

Annoyingly, it also doesn't support BigInt, which would alleviate this problem in JS as well

Re: TOML: Tom's Obvious Minimal Language

#126

I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON…

I have a wish I think is superior to trailing commas: Optional commas, like semicolons are optional in JS. Human-readable objects and arrays, like JS instructions, are nearly always already newline-separated.

Re: TOML: Tom's Obvious Minimal Language

#129
post #111

Earlier quoted context omitted.

This is such a bad take

Care to like, elaborate? Stopping people from doing brittle stuff like print("{") for elem in list: print('"key": "value",') print("}") seems like immediate worth.

That's not a very big hurdle to overcome, though:

    print("{")
    contents = ""
    for elem in list:
      contents += '"key":  "value",'
    print(contents[:-1])
    print("}")

Re: TOML: Tom's Obvious Minimal Language

#130
post #16

Earlier quoted context omitted.

That's already fixed; in the upcoming TOML 1.1 you can write: tbl = { hello = "world", } All the examples in the issue you linked should work. https://github.com/toml-lang/toml/pull/904

published data standards having version is so wrong. now if you see "config in yaml" you know nothing, zero, nada, about the format because all versions are so different and everyone implemented the version at the time and didn't bother to mention version. not to mention you can use a dozen syntaxes for yaml/toml and each application may not understand them all. all this is so silly. we will stick with json and infor…

And if you have to version it, Kelvin versioning is more appropriate for standards.
Post reply on HN