Simplify some grammar constructs. #247
Conversation
chapters/grammar.adoc
Outdated
| @@ -171,6 +160,9 @@ _postfix_expression_. | |||
| endif::ESSL[] | |||
| ==== | |||
|
|
|||
| _function_definition_ : :: | |||
There was a problem hiding this comment.
This one I just moved up, it was weirdly hanging out at the very end of the grammar, so I put it with some other function definitions.
|
I made quite a lot of simplifying changes to the grammar a few years ago but they were rejected by the working group at the time, who didn't want to make updates to the grammar at all. I'd be very happy to see the grammar improved, because I think the current version is quite a mess, but I'd like to hear that the working group will accept changes here and to see how these changes integrate with my old changes before we merge this. |
|
If your old version still applies, would you be able to push it to GitHub as a PR? I'd be curious to see it. Reading the grammar now involves a lot of jumping around and confusing, un-needed entries. I'd love to see how you simplified it and am happy to drop this PR if there is another one which does something similar. As far as I can tell, none of my changes would have any language effects, they just simplify what is currently existing. |
|
Sure, I'd be happy to push the changes. I'll dig them out (it's been a while). I agree about the jumping around and unneeded entries. A lot of it feels like it came from trying to manage data inside a yacc file rather than being a clear description of the language. My changes also didn't change the language that the grammar accepted, which I think is good while the grammar is in its current state. I do think that having the grammar accept an over-broad language and then restricting it in text is a mistake though, so it might be interesting to look at that in the future. |
| _function_prototype_ : :: | ||
| _function_declarator_ _RIGHT_PAREN_ | ||
|
|
There was a problem hiding this comment.
I've made a different change to remove this annoying rule in #252. We do need to keep function_prototype (it's referred to in function_definition, above), but if we structure it properly then this step isn't needed at all.
There was a problem hiding this comment.
Ah, good catch, I'd missed that one earlier because function_definition was weirdly at the end of the grammar instead of with the other functions.
There was a problem hiding this comment.
I merged it into function_defintion to keep this Cl correct, but either way these rules are very confusing to read.
A number of constructs in the grammar were only a single entry, or only used once (or both). This CL inlines many of these single entry constructs to the place of usage. This makes it simpler to read the grammar requiring less jumping around to determine what is permitted.
|
The bison grammar in glslang follows the grammar in the GLSL spec pretty directly, so it would be nice to see an accompanying glslang change to update that grammar as well. |
|
I agree in general that it's nice to keep the glslang grammar in sync, if only because the new grammar should be simpler than the old one, but I don't think it should be a requirement for simplifying the documentation. We should keep the spec grammar as simple and accurate as possible because it's a powerful tool for saying what's valid, while glslang may want to differ from that for implementation reasons. (Either to simplify the code or potentially to generate better error messages where "Syntax error" would be unhelpful). |
A number of constructs in the grammar were only a single entry, or only used once (or both). This CL inlines many of these single entry constructs to the place of usage.
This makes it simpler to read the grammar requiring less jumping around to determine what is permitted.