YAML and Configuration Files

YAML and Configuration Files
utcc.utoronto.ca

I need a way of expressing the core data types of JSON (key/value mappings aka "objects", arrays, strings, integers, floating points and booleans) - plus comments, and multi-line strings that insulate me from complex escaping rules.

YAML does that. It's not perfect, but it's good enough. And in Python I can use yaml.safe_load() to avoid some of the more troublesome corners of the spec.

Here's a concrete example of what I think they're complaining about. From a Kubernetes Deployment manifest:

    - name: DATABASE_URL
      valueFrom:
        secretKeyRef:
          name: db-conn
          key: uri

When attempting to express such a literal in most-any programming language, you'd expect to either have:

• the Java "literal factory function" approach — some static function to call, that takes either other literals, or a single literal string encoding an expression in a DSL, as arguments, and then produces an initialized value-object; or

• the Elixir "custom sigil" approach (there's probably a more popular language with this feature, but Elixir is what I know) — a macro or operator that takes in a raw string or lexemes encoding an expression in a DSL, and then codegens out to the appropriate structural-initialization literal. (Macros are better here, as incorrect DSL syntax can be caught at parse/compile time, just like incorrect syntax of the surrounding language.)

-----

To be honest, I don't think I would want YAML to support either of these. YAML shouldn't be arbitrarily extendable; a YAML document should be a YAML document, parsed by any compliant parser. (There could be some Avro-like "embedded schema" format for YAML that enables this, but that format would be better as a layer on top of YAML, rather than being part of YAML itself.)

What I would like in YAML, is support for built-in literal sugar for certain specific YAML structures.

This is different in concept from YAML having support for a type, where that type must have some 1:1 native type on the host language side for it to encode/decode to.

Instead, a "sugared structure" would involve

1. a YAML parser having a sub-parser for certain specific DSLs, where the output of this parser is a small, standardized-in-shape container structure, made out of regular YAML arrays, dicts, and scalars;

2. a YAML generator offering a configuration option to pattern-match on these standardized-in-shape structures, where recognized subtrees are swapped out in the emitted YAML for the appropriate sugared-literal representation.

Examples of where this would be helpful include: DateTimes, URIs, UUIDs, Intervals... and that's basically it.

There really aren't too many of these. The short list above represents basically the entirety of the set of types I've ever had YAML fall down on in the 10 years I've been generating/parsing YAML documents. For everything else, it works fine.

[1]: https://cuelang.org