Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Jul 30, 2020 at 11:07:26AM +0200, Markus Armbruster wrote: >> Andrea Bolognani <abolo...@redhat.com> writes: >> >> > The various schemas included in QEMU use a JSON-based format which >> > is, however, strictly speaking not valid JSON. >> > >> > As a consequence, when vim tries to apply syntax highlight rules >> > for JSON (as guessed from the file name), the result is an unreadable >> > mess which mostly consist of red markers pointing out supposed errors >> > in, well, pretty much everything. >> > >> > Using Python syntax highlighting produces much better results, and >> > in fact these files already start with specially-formatted comments >> > that instruct Emacs to process them as if they were Python files. >> > >> > This commit adds the equivalent special comments for vim. >> > >> > Signed-off-by: Andrea Bolognani <abolo...@redhat.com> > > Given that we already have emacs mode-lines, I see no reason to > not also have vim mode-lines, so regardless of the deeper discussion > I think this is patch is fine to merge in the short term > > Reviewed-by: Daniel P. Berrangé <berra...@redhat.com> > > >> Naming QAPI schema files .json even though their contents isn't was a >> mistake. Correcting it would be a pain. If we correct it, then the >> sooner the better. >> >> Renaming them to .py gives decent editor support out of the box. Their >> contents isn't quite Python, though: true vs. True, false vs. False. Do >> we care? Only a few dozen occurences; they could be adjusted. >> >> Renaming them to .qapi would perhaps be less confusing, for the price of >> "out of the box". > > IMHO, the critical rule is that if you a pick a particular file extension > associated with an existing language, you absolutely MUST BE compliant > with that language.
Can't argue with that :) > We fail at compliance with both JSON and Python because we're actually > using our own DSL (domain specific language). > > IOW if we're going to stick with our current file format, then we should > be naming them .qapi. We can still use an editor mode line if we want to > claim we're approximately equiv to another language, but we can't be > surprised if editors get upset. > > > The bigger question is whether having our own DSL is justified ? > > I'm *really* sceptical that it is. To be precise: our own DSL *syntax*. Semantics is a separate question to be skeptical about. > We can't use JSON because it lacks comments. So we invented our own > psuedo-JSON parser that supported comments, and used ' instead of " > for some reason. We also needed to be able to parse a sequence of > multiple JSON documents in one file. We should have just picked a > different language because JSON clearly didn't do what we eneeded. JSON is a exceptionally poor choice for a DSL, or even a configuration language. Correcting our mistake involves a flag day and a re-learn. We need to weigh costs against benefits. The QAPI schema language has two layers: * JSON, with a lexical and a syntactical sub-layer (both in parser.py) * QAPI, with a context-free and a context-dependend sub-layer (in expr.py and schema.py, respectively) Replacing the JSON layer is possible as long as the replacement is sufficiently expressive (not a tall order). > You suggest naming them .py. If we do that, we must declare that they > are literally Python code Agree. > 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. > While JSON doesn't do what we need, its second-cousin YAML is a more > flexible format. Taking one example > > --- > ## > # @ImageInfoSpecificQCow2: > # > # @compat: compatibility level > # > # ...snip... > # > # Since: 1.7 > ## > 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. > > 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 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; } > 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. Required reading on YAML: https://www.arp242.net/yaml-config.html Some of the criticism there doesn't matter for our use case.