On Fri, Dec 7, 2012 at 10:54 AM, Roman Cheplyaka wrote:

* Michael Snoyman [2012-12-07 09:52:07+0200]

...

Let me bring up one other package: yaml (written by me). I think it's a pretty good fit for the standard YAML packaging library, since it simply reuses the existing infrastructure from the aeson package (i.e. the ToJSON and FromJSON typeclasses, and the Value datatype). But I'm actually a bit concerned about proposing it, based on some history.

When I was looking at existing YAML libraries, I rejected yours when I saw JSON types. (I did see the "do not let that confuse you, it's intentional" warning, and no, it didn't help.)

Besides giving the feeling that the API is a hack, this will inevitably confuse readers of my code who are not familiar with the library and, just based on the names, will assume that the code is working with JSON, not YAML.

If you mean the naming is a hack, I agree. But if we pretend for a moment that the word JSON was actually replaced with YAML everywhere, I think the abstraction is correct. The Value datatype represents a very sane subset of YAML that people usually want to deal with. And if they want to deal with all the glories of aliases and tags, we still have the Text.Libyaml interface which preserves all information. In other words, the hack is in the name, not the abstraction.

IIUC, "all of the existing tools for JSON processing" are mainly just existing FromJSON instances. I am not sure how common this situation is, but for that you could define a newtype whose FromYAML instance would internally use the FromJSON instance of the underlying type.

It's the two typeclasses and the Value datatype. Don't underestimate the importance of reusing infrastructure here. If we had our own types and classes in YAML, then everyone who wants to include serialization classes in their packages would have to write redundant instances for both packages. Most likely, that would just mean incomplete instances for both packages. It would also mean that we'd have to duplicate libraries like aeson-lens, and duplicate all bugfixes in built-in instances, Generics code, TH code, etc. As a side benefit, the current setup allows code to remain serialization-format-agnostic. For example, Persistent can read configuration from either JSON to YAML files. Since YAML is a superset of JSON, that's not such an amazing statement, but it does mean that users can avoid an extra yaml package dependency if they really are just sticking with JSON data.

Or perhaps the JSON-agnostic subset of aeson could be extracted into a separate library, which both aeson and yaml would depend on.

I'd be very much in favor of that. I'm not so irked by the "name hack" to have bothered bringing this up with Bryan, but if he's willing to make that change, I'd certainly be grateful. I actually think it would be more logical for the typeclasses to be called ToValue and FromValue anyway, since that more directly states what they do.

As for toYAML/toJSON, I guess most of the time they are different anyway — otherwise it's defeating the purpose of YAML to be more human-readable than JSON.

I don't think that's true in practice. Most of the readability of YAML comes from the syntax, not the choice of actual serialization structure. But I could be mistaken. Michael