The Nim language in 2008 (when it was known as Nimrod) had originally been planned a similar approach of considering a unified AST with multiple "syntax skins," and as far as I understand there used to be a limited implementation of this. This would theoretically have been a boon for Nim, because an often complaint about Nim from emigrating programmers from languages with a C-style syntax was the (rather superficial) complaint - "no braces? Pythonic syntax? Yuck!"
The problem with this - and why Nim never really committed to the "syntax skin" concept - is that it would have led to far much fragmentation within Nim's own community as some users would prefer one "sub-language" over another. Given as it is the opinion of new languages (Nim included) towards a tool-based unified syntax formatting (e.g. certain naming conventions for identifiers, number of spaces for indent), "syntax skins" have become harder of a sell in favor of lingual consistency.
The original idea was that the same program could be rendered in a variety of different syntaxes in the author's IDE - but the implied maintenance cost of such skins plus that previously mentioned potential for fragmentation led to this idea falling to the wayside. Nim, as a language, grew to be quite flexible within its prime syntax over the years - e.g. the macro system (which modifies the AST directly) made way for a variety of DSLs (e.g. https://github.com/khchen/wNim#code-examples) that remain valid Nim code.
The Nim language in 2008 (when it was known as Nimrod) had originally been planned a similar approach of considering a unified AST with multiple "syntax skins," and as far as I understand there used to be a limited implementation of this. This would theoretically have been a boon for Nim, because an often complaint about Nim from emigrating programmers from languages with a C-style syntax was the (rather superficial) complaint - "no braces? Pythonic syntax? Yuck!"
https://forum.dlang.org/thread/mailman.1427.1428691340.3111....
The problem with this - and why Nim never really committed to the "syntax skin" concept - is that it would have led to far much fragmentation within Nim's own community as some users would prefer one "sub-language" over another. Given as it is the opinion of new languages (Nim included) towards a tool-based unified syntax formatting (e.g. certain naming conventions for identifiers, number of spaces for indent), "syntax skins" have become harder of a sell in favor of lingual consistency.
The original idea was that the same program could be rendered in a variety of different syntaxes in the author's IDE - but the implied maintenance cost of such skins plus that previously mentioned potential for fragmentation led to this idea falling to the wayside. Nim, as a language, grew to be quite flexible within its prime syntax over the years - e.g. the macro system (which modifies the AST directly) made way for a variety of DSLs (e.g. https://github.com/khchen/wNim#code-examples) that remain valid Nim code.