Re: [Qemu-devel] [PATCH v5 17/28] qapi: Allow true, false and null in schema json

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 04/01/2015 03:33 AM, Markus Armbruster wrote:
>
>>>> Longhand:
>>>>
>>>>     # mandatory
>>>>     'name': { 'type': 'str' }
>>>>     # optional, with a default
>>>>     'flag': { 'type': 'bool', 'default': true }
>>>>     # optional, no default
>>>>     'string': { 'type': 'str', 'default': null }
>>>>
>>>> Presence of 'default' implies optional.
>>>>
>>>> Equivalent shorthand, if any:
>>>>
>>>>     'name': 'str'
>>>>     '*string': 'str'
>>>
>>> A nice shorthand for defaults would be:
>>>
>>>     '*name': 'str' = 'default'
>>>
>>> Though that would be neither valid JSON nor Python any more. Do we
>>> actually rely on this property anywhere or is it only parsed by the QAPI
>>> generator anyway and we can extend the language in such ways?
>> 
>> I guess JSON / Python was chosen as QAPI schema language to save us the
>> bother of defining a syntax and building the tools to work with it, like
>> an Emacs mode.  JSON's not exactly my favourite choice, but at least
>> it's not XML.
>> 
>> What we have now isn't JSON, but it's still a subset of Python, and the
>> Python tools work.  If we go beyond Python, they'll break.
>
> Well, we were a subset of Python, until this patch added true, false,
> and null (the Python way would have been True, False, and None).  We are
> also similar to JSON5, http://json5.org/
>
> Among other things, JSON5 allows trailing commas, allows unquoted keys
> in a dictionary, allows single-quoted strings, and allows C-style comments.

I'm open to consider adopting it once the dust settles.

>> If we decide to sacrifice these tools for readability, then we can just
>> as well replace the syntax entirely.  Preferably by something where I
>> don't have to put every identifier in quotes.
>> 
>> In short, you're welcome to hack up qapi.py some more for schema
>> readability, but either keep Emacs Python mode working, or provide a
>> replacement :)
>
> Since we're not quite python or JSON, we've already rolled our own
> parser; so rewriting QAPI to use a syntax of our own choosing is not
> that much of a leap.

Point taken.

>                       But not for this series.

Certainly.