Re: [PATCH] schemas: Add vim modeline

[Markus Armbruster <armbru@redhat.com>]

John Snow <jsnow@redhat.com> writes:

> On 7/30/20 9:24 AM, Daniel P. Berrangé wrote:
>> On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote:
>>> Daniel P. Berrangé <berrange@redhat.com> writes:
>>>
>>>>                                modify them so that we can load the
>>>> files straight into the python intepretor as code, and not parse
>>>> them as data. I feel unhappy about treating data as code though.
>>>
>>> Stress on *can* load.  Doesn't mean we should.
>>>
>>> Ancient prior art: Lisp programs routinely use s-expressions as
>>> configuration file syntax.  They don't load them as code, they read them
>>> as data.
>>>
>>> With Python, it's ast.parse(), I think.
>>
>> Yes, that could work
>>
>
> I use a similar trick for parsing "Fuzzy JSON" inside of qmp-shell.
>
> It's cute, and I'm not really proud of it.
>
>>
>>>> struct: ImageInfoSpecificQCow2
>>>> data:
>>>>    compat: str
>>>>    "*data-file": str
>>>>    "*data-file-raw": bool
>>>>    "*lazy-refcounts": bool
>>>>    "*corrupt": bool
>>>>    refcount-bits: int
>>>>    "*encrypt": ImageInfoSpecificQCow2Encryption
>>>>    "*bitmaps":
>>>>      - Qcow2BitmapInfo
>>>>    compression-type: Qcow2CompressionType
>>>>
>>>>
>>>> Then we could use a regular off the shelf YAML parser in python.
>>>>
>
> I have a prototype where I started this, but I use "---" as a document
> separator to allow us multiple definitions per file so that the
> nesting remains pleasant.
>
> (YAML does not allow you to duplicate field names.)
>
>>>> The uglyiness with quotes is due to the use of "*". Slightly less ugly
>>>> if we simply declare that quotes are always used, even where they're
>>>> not strictly required.
>>>
>>> StrictYAML insists on quotes.
>>
>> I wouldn't suggest StrictYAML, just normal YAML is what pretty much
>> everyone uses.
>>  > If we came up with a different way to mark a field as optional
>> instead of using the magic "*" then we wouldn't need to quote
>> anything
>>
>
> I have a YAML prototype branch where I use `?field` to indicate
> optional syntax. It works just fine, at the expense of being slightly
> new to people.
>
> I tested with normal YAML, but I was thinking about adopting strict
> YAML because Markus wanted some assurance we wouldn't get lost in the
> weeds using complex feature of YAML.
>
> (Or, shoot ourselves entirely by accident.)
>
> My prototype doesn't use anything that Strict YAML prohibits, so I
> thought it was a good idea.
>
> IF -- IF IF IF IF IF we decide that actually we need the crazy
> horsepower of standard YAML, or that strict YAML is too buggy -- we
> could always just replace it. No real big deal.
>
>>> I hate having to quote identifiers.  There's a reason we don't write
>>>
>>>      'int'
>>>      'main'('int', 'argc', 'char' *'argv'[])
>>>      {
>>>          'printf'("hello world\n");
>>>          return 0;
>>>      }
>>>
>
> Fair enough ... but there's no special meaning to quoting or not
> quoting the RHS in YAML, so maybe it's best to avoid pretending like
> there's a structural semantic between an identifier and a string
> there.
>
> (Since they're both just strings, and the semantic difference is
> picked up inside the QAPI generator post-parse.)

You wish...

An unquoted right hand side is a string, unless it can be interpreted as
something else.  For instance, when something else is one of the
eleven(?) ways to say false, you have a variation of YAML's Norway
problem:

https://hitchdev.com/strictyaml/why/implicit-typing-removed/

>>>> struct: ImageInfoSpecificQCow2
>>>> data:
>>>>    "compat": "str"
>>>>    "*data-file": "str"
>>>>    "*data-file-raw": "bool"
>>>>    "*lazy-refcounts": "bool"
>>>>    "*corrupt": "bool"
>>>>    "refcount-bits": "int"
>>>>    "*encrypt": "ImageInfoSpecificQCow2Encryption"
>>>>    "*bitmaps":
>>>>      - "Qcow2BitmapInfo"
>>>>    "compression-type": "Qcow2CompressionType"
>>>>
>>>> With the use of "---" to denote the start of document, we have no trouble
>>>> parsing our files which would actually be a concatenation of multiple
>>>> documents. The python YAML library provides the easy yaml.load_all()
>>>> method.
>>>
>
> Nevermind the earlier comment, then.
>
>>> Required reading on YAML:
>>> https://www.arp242.net/yaml-config.html
>>
>> I don't think this is especially helpful to our evaluation. You can write
>> such blog posts about pretty much any thing if you want to pick holes in a
>> proposal. Certainly there's plenty of awful stuff you can write about
>> JSON, and Python.
>>
>>> Some of the criticism there doesn't matter for our use case.
>>
>> Yeah, what matters is whether it can do the job we need in a way that is
>> better than what we have today, and whether there are any further options
>> to consider that might be viable alternatives.

The sheer complexity of YAML puts me off.  The spec exceeds 20k words.

> I guess I'll dust off the work I have already to show the class.

Prototype code should beat guesswork.