Please design ANTLR5 grammar files to be always necessarily language-agnostic

[geekley]

I really dislike that in ANTLR4 you have to go out of your way to write target-agnostic grammars in the first place. That's not right. Please, for ANTLR5, just force all grammar files to be target-agnostic and design the ANTLR language around that.

Don't allow arbitrary target-language code e.g. in actions and predicates.
Instead, allow just method calls using ANTLR syntax and force all implementation to be in a separate, target language file.

For example, currently we can't even write this, without some script to translate the grammar to every target language:

// some languages use `this.`, some use `self.`, some use `this->`, some don't allow omitting `this.`, etc.
myRule: {this.myPredicate()}? MY_TOKEN {this.myAction();} ;
INVALID: ETC {false}? ; // not even this works on all languages... e.g. on Python it's `False`

Please design ANTLR5 so we could do e.g.:

myRule: $myPredicate()? MY_TOKEN $myAction() ; // language-agnostic custom method calls
INVALID: ETC $(false)? ; // allows only supported language-agnostic code; in this case a `false` expression

It's of course a simplistic example, but you get the idea.

ANTLR5 should recognize $foo() as a valid construct that will be translated to whichever syntax it needs to be in the target language of choice. It allows only a method entry point, any and all language-specific code should go out of the .g5 file.

The $(...) syntax likewise translates whichever language-agnostic code is supported by ANTLR into its equivalent for the target language (in the example, it's just an expression with false constant, but what is supported could be expanded if desired).
You could also add arguments to $foo(arg, ...) using the same language-agnostic code supported inside $(...).

If there's any other code (e.g. include headers, etc) that need to be in the target language, force them to be in separate files of that target language as well, even if it has to be like a "snippet" mini-file, if you get what I mean.

You could also do more things in the grammar itself, in language-agnostic ways.
As just a theorethical example, you could add ways to set custom error messages when failing a lexer or parser predicate.

// `!methodName()` means a `methodName()` is called to obtain a (possibly localized) string message to show
// it's just an idea, maybe you could e.g. make predicates return string|object or use some other solution
myRule: $myPredicate()!mySpecificErrCode()? MY_TOKEN $myAction() ;
INVALID_STRING: ETC $(false)!errStrContainsInvalidCharacters()? ;

---

Moved from #17 (comment)