Comments (8)
Hmm, yes, that is awkward to specify in standard CFG notation, because you really want to define <qualifiers>
in a way that makes it not allowed to expand to the empty string: you want to say that every single thing in it is optional, but one of them has to be there.
If you defined <qualifiers>
so that it had to be non-empty, you could do something like this:
<type> ::= <qualifiers> <subtype>
::= <unqualified-type>
<subtype> ::= <unqualified-type>
<unqualified-type> ::= [big list of more specific productions]
and then designate <type>
and <subtype>
as the nonterminals that are substitution candidates. That way there's always an SC for the overall type, and an extra one for the unqualified type only if at least one qualifier is present.
But in plain CFG notation it's pretty awkward to write <qualifiers>
in a way that forces it to be non-empty. The only approach I can think of is to break it up into subcases based on the first non-empty part:
<qualifiers> ::= <extended-qualifier>+ [r] [V] [K]
::= r [V] [K]
::= V [K]
::= K
and, really, yuck!
from cxx-abi.
Both the fully-qualified and unqualified types need to introduce substitution candidates, but we shouldn't do it twice for unqualified types. I'm hesitant to do some major refactor of the tree, but if you can find a clean solution, I'm open to taking it.
from cxx-abi.
Yeah. Unfortunately, I think this is a situation where creating a formally correct and unambiguous grammar is actually in tension with clarity for human readers, which seems like the more important goal. I'm inclined to just close this, but I can leave it open if you'd like to continue thinking about it for a while.
from cxx-abi.
No argument there – of course I agree that clarity for humans is more important. But it would be nice if we could also have a reference parser that verifiably matches the spec.
Would you be open to a compromise in which the grammar is refactored as in the first snippet above, but with the RHS reference to <qualifiers>
simply adding a note that it must be non-empty?
<type> ::= <qualifiers> <subtype> # but only if <qualifiers> is non-empty
::= <unqualified-type>
<subtype> ::= <unqualified-type>
<unqualified-type> ::= [big list of more specific productions]
That loses the really ugly part, which is the cumbersome redefinition of <qualifiers>
via lots of horrible repetitive productions to force it to be non-empty.
I don't know that you could make an LR parser generator accept a grammar in this unusual representation (even if you wrote a custom one), but I do know that the simpler and more brute-force Earley algorithm would cope with it fine. Perhaps that would still be adequately clear to humans, while also permitting at least one parsing technology to handle the grammar?
from cxx-abi.
Yeah, I think a note saying that <qualifiers>
must be non-empty (and maximal?) would be totally reasonable.
from cxx-abi.
I'd prefer just "non-empty", and to handle "maximal" by reorganising the grammar to ensure it can't generate two adjacent <qualifiers>
. "Maximal" is a harder property to check for automatically!
from cxx-abi.
Do you have a suggestion of how to do that which doesn't look awful?
from cxx-abi.
I thought the suggestion in my last-but-one comment was reasonably minimal, just rearranging the top-level rule or two for <type>
, and annotating the one use of <qualifiers>
with a note saying this rule is only valid if it's non-empty. With that, <qualifiers>
itself wouldn't have to be modified at all.
(It does mean there's no formal representation of that non-emptiness requirement. But I don't think there'd be any clean way to do that unless you introduced some kind of exciting new syntax for grammar rules, like "lhs ::= rhs1 AND NOT rhs2"!)
from cxx-abi.
Related Issues (20)
- Should std::rethrow_exception be covered by the EH ABI? HOT 2
- Emergency EH buffer is overspecified HOT 6
- Where is the most recent ABI document? HOT 1
- Add `[[trivial_abi]]` attribute
- Lambda POD for the purposes of layout? HOT 2
- Mangling the name of an externally visible lambda in a static data member of a class HOT 1
- Proposal: Include an optional specification for mangling names that reference anonymous symbols HOT 4
- Is it possible to form a pointer-to-data-member with offset -1 using explicit derived-to-base conversions without UB? HOT 3
- unnecessary `E`s after <expression> and mangling collisions between <expression> and <number> HOT 1
- need mangling for lambdas appearing in unevaluated operands within a class body HOT 3
- What does "forbidding the use of function templates" mean? HOT 2
- [C++20] [Modules] Do we need the concept of `key function` for class defined in module purview? HOT 25
- Missing HTML encoding in 2.3.1 Data Member Pointers HOT 2
- Proposal: document or somehow notice __cxa_init_primary_exception HOT 3
- Mangling for C++ pack indexing HOT 1
- Function and function pointer types with vendor calling conventions HOT 2
- Question about section 2.9.4 HOT 4
- Questions About Non-POD Types Data Layout HOT 3
- New mangling rule for deduced default template arguments. HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cxx-abi.