yaml and aeson Was: Growing Haskell Platform

[Michael Snoyman]

On Fri, Dec 7, 2012 at 10:54 AM, Roman Cheplyaka <roma at ro-che.info> wrote:

> * Michael Snoyman <michael at snoyman.com> [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121207/cd15b2e6/attachment.htm>