6 ms·

I totally feel you on the implementation side. The formalization used in the spec leaves a lot to be desired, and the spec devs seem to recognize this well. One

I totally feel you on the implementation side. The formalization used in the spec leaves a lot to be desired, and the spec devs seem to recognize this well. One of the aims of my dayaml[0] project is to explore a completely different formalization that rationalizes out the non-fundamental sharp edges. That said, there really aren't that many special cases. A lot of the them are UI features, arguably endemic to the problem space in one form or another. The deficiencies you see in the language, however, don't ring true with me. They are mostly implementation deficiencies: - Anchors are just pointers. YAML can efficiently represent generic object graphs, but if a loader copies those pointers into a billion laughs, that's an issue with the implementation decision. Usually, it comes down to assuming that YAML graphs are always trees, which will always turn cyclic graphs into infinite tree unfoldings. - Keys are explicitly specced as unique [1]. Not really sure why libyaml and friends get this wrong. - Loading YAML to objects is explicitly designed to represent the native data structures of your language. It's a serialization format by design. That's why it loads into objects. That's why it has complex keys. We can certainly discuss whether YAML is appropriate as a configuration language or not, but YAML is first and foremost designed as a language-agnostic textual representation of object graphs. The spec goes well out of it's way to make this clear, and viewing YAML for what it is, instead of a configuration language, really makes the apparent oddities disappear IMHO. [0]:https://github.com/xelxebar/dayaml https://github.com/xelxebar/dayaml [1]:https://yaml.org/spec/1.2.2/#mapping https://yaml.org/spec/1.2.2/#mapping [2]:https://yaml.org/spec/1.2.2/#11-goals https://yaml.org/spec/1.2.2/#11-goals

Ygg2 2y ago
> Anchors are just pointers. > That's why it has complex keys. Yes. And it leads to exploits or errors. The dumber the serialization format, the better. JSON has thrived without these mis-features. And most stuff I've seen in the wild doesn't use the exotic features anyway. The format user should worry about converting nodes to references, and complex keys are something few users ask for.
- xelxebar 2y ago
  > it leads to exploits or errors You are blaming implementation failures on the language design. That's kind of my whole gripe. Instead of wasting cycles on inventing new languages, I wish we'd pool resources into fixing libyaml. > most stuff I've seen in the wild doesn't use the exotic features anyway Mostly due to lack of awareness. Ruby, Python, JavaScript Rust, Java, etc. all allow mostly arbitrary objects for keys. It's only confusing if you conflate dictionaries/maps for objects. In the scientific computing community, it's not unheard of to see lists as keys in YAML documents, which is really convenient if that serializes to exactly the data model you're working.

Ygg2 2y ago

> Anchors are just pointers. > That's why it has complex keys. Yes. And it leads to exploits or errors. The dumber the serialization format, the better. JSON has thrived without these mis-features. And most stuff I've seen in the wild doesn't use the exotic features anyway. The format user should worry about converting nodes to references, and complex keys are something few users ask for.

xelxebar 2y ago
> it leads to exploits or errors You are blaming implementation failures on the language design. That's kind of my whole gripe. Instead of wasting cycles on inventing new languages, I wish we'd pool resources into fixing libyaml. > most stuff I've seen in the wild doesn't use the exotic features anyway Mostly due to lack of awareness. Ruby, Python, JavaScript Rust, Java, etc. all allow mostly arbitrary objects for keys. It's only confusing if you conflate dictionaries/maps for objects. In the scientific computing community, it's not unheard of to see lists as keys in YAML documents, which is really convenient if that serializes to exactly the data model you're working.