[Haskell-cafe] A new yaml module

[Michael Snoyman]

I've made an initial stab at this new API. It lives in two modules:
Data.Yaml.Builder, and Data.Yaml.Parser. Both of these modules are highly
inspired by the aeson equivalents, but they allow for more control of
serialization, and proper handling of ambiguous values like 12345, which
can now be parsed as either an Int or a Text.

In order to make it easier to experiment with this API, I've included these
two modules in the most recent version of the yaml package on Hackage[1].
Note that:

* The API isn't fully fleshed out. In particular, many ToYaml and FromYaml
instances need to be written.
* The API is subject to change over the next few iterations, so please
don't start depending on it yet.

Discussion on this API has been taking place on the issue tracker[2]. You
can see some simple example usages of the API at [3][4].

[1] http://hackage.haskell.org/package/yaml-0.8.7
[2] https://github.com/snoyberg/yaml/issues/38
[3] https://github.com/snoyberg/yaml/blob/master/builder-test.hs
[4] https://github.com/snoyberg/yaml/blob/master/parser-test.hs


On Mon, Feb 3, 2014 at 10:57 AM, Michael Snoyman <michael at snoyman.com>wrote:

> The yaml package[1] currently provides two modules. Text.Libyaml is a
> lower level, streaming API which is essentially a raw exposure of the
> underlying libyaml C library. Data.Yaml uses the aeson Value data type and
> ToJSON/FromJSON type classes for higher level serialization. For many
> cases, this approach works well, though there are problems:
>
> * There are problems with roundtripping, since YAML allows for ambiguity
> about the data type of values[2]. For example, in the yaml snippet `foo:
> 1234`, is 1234 intended to be numeric or a string? Either is valid.
> * YAML is intended to be human-readable output. But Data.Yaml provides no
> control over the encoded representation, e.g. should we use single or
> double quotes for a string (or no quotes at all), or the order of values in
> a mapping[3].
>
> For other examples, just look at the issue tracker for yaml[4].
>
> I don't want to drop the current aeson-based functionality, since I think
> it's still valid and useful in many cases. But I do think it's worthwhile
> to add in an alternative API which handles YAML-specific constructs better.
> My idea is:
>
> * Create a new Data.Yaml.Aeson module, and have it mirror Data.Yaml.
> * Deprecate Data.Yaml.
> * Create a new Data.Yaml.? module to contain this YAML-specific API.
>
> I'm asking for feedback on that last point. I have some basic ideas on
> what such an API would look like, but given that there are many people
> using YAML in ways different than how I'm using it, I don't think an API
> designed entirely by me will suit all use cases.
>
> I've opened up a new issue[5] to track this work. If you're interested in
> participating in this design, please contact me. I'm happy to have the
> discussion on this mailing list, but if (as I suspect) there are just a
> handful of people who are interested in pushing this forward, it likely
> makes sense to take the discussion offlist.
>
> Michael
>
> [1] http://hackage.haskell.org/package/yaml
> [2] https://github.com/snoyberg/yaml/issues/22
> [3] https://github.com/snoyberg/yaml/issues/37
> [4] https://github.com/snoyberg/yaml/issues
> [5] https://github.com/snoyberg/yaml/issues/38
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140211/29034962/attachment.html>