<p>When designing a programming language, before even writing the compiler's code, what are existing tools allowing to write a grammar, which can then check it for ambiguities and test it with sample inputs ?</p>
<p>For example there is Antlr CLI: <a href="https://github.com/antlr/antlr4/blob/master/doc/tool-options.md" rel="noreferrer">https://github.com/antlr/antlr4/blob/master/doc/tool-options.md</a>, any other tools that can be used early in the design process ?</p>

<language-design><grammar><recommendation>
What are grammar checker tools that can be used when designing a new language?
CC BY-SA 4.0
2023-05-23T22:07:57.463Z
Welcome to PLDI! This is pretty opinion based currently, since what's best will depend heavily on what language you're using, what sort of language you're making, and what your priorities are (performance, helpful error messages, etc.). Rephrasing it to be more about the reasons you'd pick one over another will help you to get more objective answers.
rydwolf
CC BY-SA 4.0
2023-05-23T22:15:53.913Z
Formal language theory concerns itself with ambiguities, but if you're writing a real programming language, you'll usually just cherrypick the "more intuitive" parse in that case. You deal with ambiguity by just deciding which one looks better.
Silvio Mayolo
CC BY-SA 4.0
2023-05-25T08:09:59.767Z
Relevant meta quesiton about recommendations - https://languagedesign.meta.stackexchange.com/questions/261/should-we-allow-questions-asking-to-find-or-recommend-off-site-resources/262#262
Bruce Adams
CC BY-SA 4.0
2024-06-19T01:33:23.007Z
https://mdaines.github.io/grammophone/#/
blueberry
<p>This is more of a prototyping approach than a &quot;checking&quot; approach, but in the past, I have relied on LR parser generators which take a grammar-like input specification, check it for LR validity, and generate a parser for the specification.</p>
<p>Specifically, in Rust, I have made use of the <a href="https://lalrpop.github.io/lalrpop/" rel="noreferrer">LALRPOP</a> tool for building parsers while I am in the &quot;ideation&quot; phase, and LALRPOP can produce helpful errors for a number of LR parsing ambiguities and issues.</p>
<p>Notably, I am pretty sure that LR parser generators tend to be somewhat strict, and may prevent you from expressing an otherwise valid or unambiguous production in your grammar, so it may not be suitable for all grammars or all levels of implementation.</p>

CC BY-SA 4.0
2023-06-05T14:48:12.383Z
2023-06-05T14:48:12.383Z
quiet_laika
<p>I saw tools for the automatic generation of random inputs, according with one specific grammar rule. All this in Smalltalk (SmaCC and PetiteParser had tools like that). But those was mechanisms (I guess) a bit different from what you are talking. They was viable because the two generators both had the lexer and the parser tied together.</p>
<p>Maybe more near to what you have in mind is another tool (still in Smalltalk). Ohm (which is the new incarnation of OMeta) and PetiteParser both gives the developer the freedom to test each grammar rule individually.</p>
<p>And that possibility is given by the particular design of those compilers, which are based on the concept of incremental composition of simple grammars. The whole parser is (maybe) a bit slower than other compiled and optimized grammars, but the phase of testing (which is hard, when the syntax is not super-simple, e.g. JavaScript is hard to test extensively) results more workable.</p>
<p>I'm personally working on a C++/JavaScript parser built with that logic and its not easy, but it is doable.
I started with a parser for Lua... and testing it was a joke.
Testing C++ or JavaScript... no, it's definitely not a joke.</p>

CC BY-SA 4.0
2024-06-18T12:20:01.817Z
2024-06-18T12:20:01.817Z
pber
# What are grammar checker tools that can be used when designing a new language?
Posted by: username_0 on 2023-05-23
When designing a programming language, before even writing the compiler's code, what are existing tools allowing to write a grammar, which can then check it for ambiguities and test it with sample inputs ?

For example there is Antlr CLI: <https://github.com/antlr/antlr4/blob/master/doc/tool-options.md>, any other tools that can be used early in the design process ?
**Tags:** language-design grammar recommendation
> **Comments:**
> **username_1**: Welcome to PLDI! This is pretty opinion based currently, since what's best will depend heavily on what language you're using, what sort of language you're making, and what your priorities are (performance, helpful error messages, etc.). Rephrasing it to be more about the reasons you'd pick one over another will help you to get more objective answers.  
> **username_2**: Formal language theory concerns itself with ambiguities, but if you're writing a real programming language, you'll usually just cherrypick the "more intuitive" parse in that case. You deal with ambiguity by just deciding which one looks better.  
> **username_3**: Relevant meta quesiton about recommendations - https://languagedesign.meta.stackexchange.com/questions/261/should-we-allow-questions-asking-to-find-or-recommend-off-site-resources/262#262  
> **username_4**: https://mdaines.github.io/grammophone/#/  
---
## 2 answers
### Answer by username_5 on 2023-06-05. Score: 6
This is more of a prototyping approach than a "checking" approach, but in the past, I have relied on LR parser generators which take a grammar-like input specification, check it for LR validity, and generate a parser for the specification.

Specifically, in Rust, I have made use of the [LALRPOP](https://lalrpop.github.io/lalrpop/) tool for building parsers while I am in the "ideation" phase, and LALRPOP can produce helpful errors for a number of LR parsing ambiguities and issues.

Notably, I am pretty sure that LR parser generators tend to be somewhat strict, and may prevent you from expressing an otherwise valid or unambiguous production in your grammar, so it may not be suitable for all grammars or all levels of implementation.
---
### Answer by username_6 on 2024-06-18. Score: -1
I saw tools for the automatic generation of random inputs, according with one specific grammar rule. All this in Smalltalk (SmaCC and PetiteParser had tools like that). But those was mechanisms (I guess) a bit different from what you are talking. They was viable because the two generators both had the lexer and the parser tied together.

Maybe more near to what you have in mind is another tool (still in Smalltalk). Ohm (which is the new incarnation of OMeta) and PetiteParser both gives the developer the freedom to test each grammar rule individually.

And that possibility is given by the particular design of those compilers, which are based on the concept of incremental composition of simple grammars. The whole parser is (maybe) a bit slower than other compiled and optimized grammars, but the phase of testing (which is hard, when the syntax is not super-simple, e.g. JavaScript is hard to test extensively) results more workable.

I'm personally working on a C++/JavaScript parser built with that logic and its not easy, but it is doable.
I started with a parser for Lua... and testing it was a joke.
Testing C++ or JavaScript... no, it's definitely not a joke.
---
