In OSH I use the technique of "lexer modes" to handle all the cases you mention: http://www.oilshell.org/blog/2017/12/17.html http://www.oilshell.org/blog/201

In OSH I use the technique of "lexer modes" to handle all the cases you mention: http://www.oilshell.org/blog/2017/12/17.html http://www.oilshell.org/blog/2017/12/17.html I have a few more blog posts on that topic I haven't published, but hopefully that gives the idea. I probably used to agree with you (if I'm understanding correctly; it's not entirely clear what the conflict you see is). But after writing the parser in this style, I don't think it's too big a deal. I plan to use the same technique to parse the Oil language, which is a new language without the legacy. The command syntax is largely the same, but compound constructs like function, if, while/for, etc. are different. The parser is regularly tested on over a million lines of shell: http://www.oilshell.org/blog/2017/11/10.html http://www.oilshell.org/blog/2017/11/10.html Note that Python, JavaScript, and Swift all need something like this too, now that they have arbitrary code inside string literals, just like shell: print(f'three = {1 + 2}') # Python f-strings console.log(`three = ${1 + 2}`) # JavaScript println("three = \(1 + 2)") # Swift