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

[Michael Spencer via llvm-dev]

On Mon, Oct 30, 2017 at 4:16 AM, Sam McCall <sammccall at google.com> wrote:

> 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).
>

Ah, yeah.

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.
>

Tagged union works with YAMLIO, the MachO YAML interface uses it (see
MappingTraits<MachOYAML::LoadCommand>::mapping). By usability I was mainly
referring to the verbosity and non-JSONness of YAMLIO.


>
> 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.
>

Thanks for looking into this.

- Michael Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171030/c5ba89cc/attachment.html>