[llvm-dev] RFC: Adding a JSON library to LLVM Support

[Sam McCall via llvm-dev]

On Sun, Oct 29, 2017 at 11:19 PM, Michael Spencer <bigcheesegs at gmail.com>
wrote:

> On Fri, Oct 27, 2017 at 1:53 PM, Sam McCall via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> We don't have a dedicated JSON library in the LLVM tree, I'd like to add
>> one. The pressing need is for clangd, but we have other tools that
>> read/write JSON too.
>>
>> I'm proposing we write a new one, rather than importing a third-party
>> library (licensing/integration reasons), on or extending YamlParser/YamlIO
>> (usability/flexibility). I lean towards a design that parses a full DOM at
>> once, and provides literal-like syntax for composing documents.
>>
>> I've written a document laying out the reasons for taking this path, and
>> my proposal for a design (with links to a prototype)
>> https://docs.google.com/document/d/1OEF9IauWwNuSigZzvvbjc1cV
>> S1uGHRyGTXaoy3DjqM4/edit
>> (Comments are enabled, but high-level discussion probably belongs on the
>> list instead.)
>>
>> What do you think? I'm particularly interested in which parts of LLVM
>> produce/consume JSON (or might want to), and what they need. I'm mostly
>> familiar with the stuff in clang-tools-extra.
>>
>> Cheers, Sam
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
> The technical problems you've listed for YAMLIO aren't fundamental to the
> design of the library, and wouldn't be too hard to fix (it already has
> output support).
>
Right! Sorry if that was misleading: I meant it can't be used for writing
_JSON_ today (whereas reading does work).


> However the usability concerns you have are pretty fundamental to the
> design, as it's designed for strong typing as opposed to exposing a DOM.
>
Yeah. The tagged-union format is unfortunate in its requirement for out of
order parsing (though it is strongly typed!)
The protocol is driven by the fact that everyone *else* uses DOM parsers, I
think.

An alternative I would suggest looking at is adding a JSON mode to
> YamlParser and then adding a YAML compatible DOM API similar to what you've
> proposed on top of that. I could see this being more complex/less usable
> than a dedicated JSON parser, but just want to make sure it's weighed
> against the cost of adding yet another parser.
>
Sharing the parser might make sense. On the other hand the JSON grammar is
so simple that JSON enforcement in YAMLParser may be more complex than a
standalone parser, and would certainly be slower. I'll do some experiments
here.
I'm less convinced about a YAML-compatible DOM: tree vs arbitrary graph is
a pretty big difference, to start.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171030/b3f2820f/attachment.html>