News for hackers. Stuff that matters.
Re:Design Guidelines for Domain Specific Languages by marcosdumay on Thursday November 09, 2023 @09:45AM (#38205616)
Hum... A grammar conflict on parser combinators always require that you step down from the parser abstraction and resolve it by hand with basic language functionality, doesn't it? It's something quite hard to notice.

Are you concerned with the documentation getting out of sync with the actual language?

Re:Design Guidelines for Domain Specific Languages by victorNicollet on Thursday November 09, 2023 @10:10AM (#38205976)
In a situation where I'm adding a new feature to the language, with a new syntax that causes me to add a new rule to the grammar, I'm concerned that the new rule will accidentally "capture" some code that already exists in the wild, that was previously derived by another part of the grammar.

To give a very ugly example, if you have a language with function calls f(expr, expr, expr) and you want to add tuple syntax to expressions with a brand new rule:

  expr := expr COMMA expr
Then you might have accidentally turned all functions into unary functions, as the tuple rule captures the "expr, expr, expr" part and leaves you with f(expr).