6 ms·
Anyone have a suggestion for an alternative to YAML that's easier to write by hand than JSON and also supports nested declarations? ("XML with a fancy text edit
by bogwog 3y ago
Anyone have a suggestion for an alternative to YAML that's easier to write by hand than JSON and also supports nested declarations? ("XML with a fancy text editor" doesn't count)
I have a project where I'm using YAML just for that: nested tree-like (data) declarations and reasonably succinct and relaxed syntax. I have run into some of YAML's parsing weirdness occasionally, but overall it hasn't been that bad to deal with when it happens.
- lelanthran 3y ago> Anyone have a suggestion for an alternative to YAML that's easier to write by hand than JSON and also supports nested declarations? ("XML with a fancy text editor" doesn't count) S-expressions. A parser for s-expressions (with no evaluation) can be as small as 300 lines of C code. It'd take a day to write, and can express everything in a way that: 1. Current IDEs and code-editors can semantic-highlight 2. Current IDEs and code-editors can auto-format Add in builtins for setting/getting symbols, and you can also DRY your config with variables and functions. [EDIT: The DRY is optional - if you don't want someone messing up configs down the line, then don't implement any builtins that modify the symbol table, just examine the tree in your program after you have read in the s-expressions.]
- xigoi 3y agoS-expressions don't have associative arrays (maps/dicts/objects), which are very important for config.
- lelanthran 3y agoS-expressions don't have anything. They can represent almost everything, though. Composite data types, nested objects, alists, lists, trees, tables... With only a few primitive additions, you should be able to represent everything, except for bidirectional cyclic graphs.
- mbakke 3y agoBut then you have to evaluate things, which brings all kinds of problems. Your parser is no longer 300 lines, and eventually you might snap and throw it all away for a full-blown interpreter which makes dealing with user provided input difficult. I'm actually investigating using S-expressions for describing jobs and systems, but haven't figured out how to safely evaluate them short of running in isolated VMs. Edit: thinking more about this, it is possible to represent all those things without evaluation. It's just awkward to create them... but that can be solved on a different level.
- waffletower 3y agoThere is a discussion above regarding EDN, which supports S-expressions, has maps, sets, and vectors (JSON style collection syntax []). I think it could be an excellent replacement for YAML in some important use cases, but it is lacking for representing inline, non-Lisp code and heredocs.
- verdverm 3y agohttps://cuelang.org https://cuelang.org | https://cuetorials.com https://cuetorials.com
- paulddraper 3y agoTOML Though stylistically it appears flat. HOCON Though if you're trying escape complexity, it doesn't count. Jsonnet Though this is Turing-complete.
- kagakuninja 3y agoI'mm fond of HOCON, not sure if it can be used as a pseudo programming language like YAML. It is great for config files.
- ihumanable 3y agoI'm kinda curious what's so difficult about writing JSON. I imagine it's quite subjective, but I've found the explicit bit of JSON to be nice. My editor is going to spit out matching brackets, quotes, braces, etc. I think, at least for me, when I'm writing JSON in a document I can just go "I need a map, type `{`" and "I need a list, type `[`" and I like that. I think my biggest gripe with YAML, TOML, etc is that to save me a few keystrokes I often end up playing this game of "Ok now how will the library interpret this, I'm adding a line here, it's indented, let me scroll up, ok, the last logical thing that happened was X so it's going to interpret this as a list item..." and that feels so taxing to me.