Is there a source on Van Vijngaarden grammars that’s even barely readable to the modern eye (and more detailed than Wikipedia)? I tried a number of contemporary papers, and they’re impressively impenetrable when they try to define the whole thing inside a page and a half—which is entirely unsurprising even if you set aside the prehistoric terminology (“notions” are ... nonterminals? or maybe all symbols? I can’t tell).
In any case, there’s something to be said for defining a language in a series of layers: tokens, then trees, then perhaps elaboration / desugaring, then one or more layers of semantics (typing, binding, execution). In an actual frontend, you probably even want a looser tree syntax followed by a layer of “semantic” checks that could technically be folded into the syntax, in order to be able to tell the user things like “you can’t use an array type like that” rather than “unexpected bracket”. Compare Lisp s-expressions, the Dylan idea of skeleton syntax trees, and the class of visibly pushdown languages as used in one recent structural editor[1]. Contrast the refusal of the Glasgow Haskell Compiler to desugar before typechecking[2].
In any case, there’s something to be said for defining a language in a series of layers: tokens, then trees, then perhaps elaboration / desugaring, then one or more layers of semantics (typing, binding, execution). In an actual frontend, you probably even want a looser tree syntax followed by a layer of “semantic” checks that could technically be folded into the syntax, in order to be able to tell the user things like “you can’t use an array type like that” rather than “unexpected bracket”. Compare Lisp s-expressions, the Dylan idea of skeleton syntax trees, and the class of visibly pushdown languages as used in one recent structural editor[1]. Contrast the refusal of the Glasgow Haskell Compiler to desugar before typechecking[2].
[1] https://news.ycombinator.com/item?id=31384528
[2] https://www.aosabook.org/en/ghc.html