Michael Snoyman | 7 Dec 10:51 2012

yaml and aeson Was: Growing Haskell Platform




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 
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Roman Cheplyaka | 7 Dec 11:00 2012

Re: yaml and aeson Was: Growing Haskell Platform

* Michael Snoyman <michael <at> snoyman.com> [2012-12-07 11:51:40+0200]
> > 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.

Not the serialization structure, no.

I meant that YAML has some flexibility in syntax, which probably should
be exploited by the instance writer to improve readability.

For that you'd need a sufficiently adjustable pretty-printer, but that
also means that you can't reuse ToJSON.

Roman

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Michael Snoyman | 7 Dec 11:24 2012

Re: yaml and aeson Was: Growing Haskell Platform




On Fri, Dec 7, 2012 at 12:00 PM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
* Michael Snoyman <michael <at> snoyman.com> [2012-12-07 11:51:40+0200]
> > 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.

Not the serialization structure, no.

I meant that YAML has some flexibility in syntax, which probably should
be exploited by the instance writer to improve readability.

For that you'd need a sufficiently adjustable pretty-printer, but that
also means that you can't reuse ToJSON.

Roman


I see what you mean. You're talking about pretty-printing features such as how strings get quoted. That's true, to have full support for this, you can't use the ToJSON interface, but instead need to use the Text.Libyaml low-level interface. IMO, that's an acceptable trade-off. I consider the readability of YAML much more important for human-generated files. But if you'd like to see a higher-level interface which allows more control, I see no problem with adding it in.

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Gmane