Hacker News Reader

Comment by chme | Hacker News Reader

Interesting, but the first thing I checked was if it allows list elements to have different types. And it doesn't.

That was one issue I had with TOML, because the allowed data schema is not JSON compatible. Switching from YAML or JSON to TOML or SAN is therefore often difficult and as such easier to just stay with the one that is currently used.

For new projects, it might be nice. But having to work around this limitation when you need it is also a bit annoying.

View on HN

I think we need to start distinguishing between data formats and configuration formats. JSON is a data format. I loathe working with NodeJS because of the necessity of hand-editing JSON, and that just makes me want to bash my head against the wall.

In my side projects, generally I'll hand-write a parser with regular expressions because I haven't yet found one I actually like both looking at and editing. I can fix every single other problem except that one. With SAN, the issue is the bracket delimiters. I hate futzing with them, just let me use tabs. I want this:

  Monthly Recurring
  	Patreon: 8 | 9/17/2018 | 2mo - Acc: Capital One - Tags: arts
  	Workflowy: 4.99 | 9/17/2018 | 6mo - Acc: Amex - Tags: tools
  	RubyTapas: 15 | 9/17/2018 | 6mo - Acc: Amex - Tags: education
  	Verizon: 70.17 | 9/17/2018 | 6mo - Acc: Amex - Tags: utilities,tools

This is easy to look at, easy to edit with a text editor, and, once the parser's written, dead simple with Ruby POROs, easy to parse into queryable data structures.

I have yet to find any format that's intended to be human-editable that doesn't actually feel 'nice to the touch'. So I just make my own.

When hand-editing the format above, I generally don't type in a whole line at a time. I'll just add in the basics, and fill it out later, perhaps with machine processing. Tags in particular are easy to copy-paste in by hand and are generally the last part of the line.

While I like python style indentation I absolutely cannot accept unquoted strings. Bonus points for a good multiline string format.

I hate, hate, hate the ambiguity and the flavor of the week tokenization/operator precedence/does it trim whitespace questions.

This is JSON's biggest strength: it's trivially unambiguous.

Try Dixy :)

https://github.com/kuyawa/dixy

Someone else's hand-rolled parser isn't going to be my hand-rolled parser.

Hi, good reply.

The reason for brackets are auto formatting by the san CLI (think go/rust fmt)

With a data format, you need auto-format, you have no idea what shape it's going to be in and it has to handle arbitrary everything. With a configuration format, you want a highly consistent structure, the machine should be able to output it just with print statements.

If my configuration needs auto-formatting, something's gone very very wrong in the design of my application.

The other way SAN isn't json compatible is lack of null.

As for heterogenous list types, great reason to have them is when your list is logically the same type but physically isn't.

In some formats like Cargo.toml, the following are equivelant:

    dep="1.8"
    dep={version="1.8"}

This allows a short-hand for the common case. Being able to do this in lists would improve the file formats I've been making.

I used lists to build my own include concept in yaml like so:

    includes:
      - relative-include-file.yml
      - url: git://stuff.git
        file: git-included-file.yml

Not possible here.

(Of course I would need to change the string to a map as well, but that is just clunky to write all the time.)

That's the point, we didn't ever find a good reason to use heterogeneous lists.

They can all be replaced by maps which may seems more verbose but carry in fact far more information and clear

For me a configuration file should be easy to write and read while not taking so much care about the data types.

So for me you get a shoe if you reverse your argument. Type limitations aren't improving write or readability IMO and just make it harder, because you have to think about using the right type. Application specific schema checkers should take care of the checking the type.

Reply on news.ycombinator.com