- From: Armen Michaeli via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Sep 2024 12:39:13 +0000
- To: public-css-archive@w3.org
If the specification is intended to be readable, which I think _is_ a worthy goal, naturally -- since it's meant to be read by humans, after all, including the provided grammar, -- then perhaps it could be in the very least useful to define "equivalence" criteria between rules expressed with the grammar and alternatives that e.g. you suggest above, but which admit/refuse the same set of input (don't necessarily parse equivalently, since the concrete syntax tree is different, but otherwise "equivalent"). That way, if an implementation chooses to rewrite a grammar production for the sake of optimization, taking into account some peculiarities of the implementation that benefit from or outright demand the alternative production expression (an "optimizated" variant), at least the implementation can rightfully claim adherence to the specification. As it is today, since the specification doesn't say whether the grammar is to be followed _exactly_, or how much leeway there may be had in interpreting and implementing it, questions like my own above are valid, I guess. And while your suggestion(s) are valid in more general context, if the grammar is part of the spec. _as-is_, then the suggested alternatives are in violation of the spec. And I, for one, would like to know how much leeway there is for an implementer. Grammar is quite decisive for a parser -- like you yourself said, it makes for a tangible difference for a parser how a production is composed. Certain kinds of parsers, for example, are unable to handle left- or right- recursion in the grammar, and although current grammar does not productions exhibiting such issues, if rewriting grammar is "not permitted", there's even less leeway for an entire class of parsers that are already grammar-bound. -- GitHub Notification of comment by amn Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10944#issuecomment-2373972435 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 September 2024 12:39:14 UTC