3 ms·

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

by chme 8y ago

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.

epage 8y ago
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.
- chme 8y ago
  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.)
  - z0mbie42 8y ago
    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
    - chme 8y ago
      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.
vinceguidry 8y ago
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.
- z0mbie42 8y ago
  Hi, good reply. The reason for brackets are auto formatting by the san CLI (think go/rust fmt)
  - vinceguidry 8y ago
    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.
- Entangled 8y ago
  Try Dixy :) https://github.com/kuyawa/dixy https://github.com/kuyawa/dixy

by chme 8y ago

epage 8y ago

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.

chme 8y ago
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.)
- z0mbie42 8y ago
  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
  - chme 8y ago
    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.

vinceguidry 8y ago

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.

z0mbie42 8y ago
Hi, good reply. The reason for brackets are auto formatting by the san CLI (think go/rust fmt)
- vinceguidry 8y ago
  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.
Entangled 8y ago
Try Dixy :) https://github.com/kuyawa/dixy https://github.com/kuyawa/dixy