search

Minres / CoreDSL

Xtext project to parse CoreDSL files
Apache License 2.0
14 stars 2 forks source link

Decide strategy for grammar design #40

Closed jopperm closed 2 years ago

jopperm commented 2 years ago

While thinking about @AtomCrafty's recent proposals (#34 #37 #38 #39), I realised (again) that through the Yacc grammar, the current CoreDSL 2 grammar is based on the C specification. All the weird names and categorisations ({labeled/jump/iteration}Statement) originate from there.

My thinking is: Should we better stay close to the naming in the C spec, which we reference in CoreDSL as a fall-back anyways, because the C spec is something people tend to know/agree on? Is our main problem maybe that our Xtext-port of the Yacc-grammar is faulty and has resulted in the terrible object model Mario is trying to fix piece by piece?

What I mean is, could we adapt the general structure of the C spec (and get operator precedences etc. right "for free"), while taking care that the grammar follows Xtext's best practices and generates a "good" AST?

/cc @eyck

eyck commented 2 years ago

Actually the Xtext grammar is directly derived from the C EBNF. This is used to build LALR parser generators (like yacc). So there are small adaptations to be LL compatible. So the class names and their hierachy stem from this grammar. I guess this boils down to: do we keep the C grammar rules names (which I think only a few people are concerned on) or do we transform the grammar and its rule/class names to something more sensible. My view here is: stay as close as possible to the syntax to C, ignore the grammar of C.

AtomCrafty commented 2 years ago

I agree with Eyck, we should prioritize readability and expressiveness over correlation to the C grammar. Also keep in mind that the C standard is ancient and terminology has changed quite a bit since the 70's.

Some of the issues do stem from the fact that we're constrained to an LL grammar, like the whole assignment expression debacle. And yes, the LL transformation did introduce some errors, like the operator associativity. But many of the changes I'm trying to make are unrelated to that.

What I mean is, could we adapt the general structure of the C spec

I'm not exactly sure what you mean by this, but a straight transcription of the C grammar rules is not possible, because of the mentioned LL constraint.

jopperm commented 2 years ago

Ok!