Wow this is a great idea - I’ve needed a bunch of variations
a =>.t b could return [a, b.value(a)]
etc…
That’s not accurate. I said I wouldn’t prioritize supporting nonstandard syntax because it’s outside my current needs, and invited others to research the tooling themselves to see if it would meet their needs, and also indicated I would be receptive to feedback (including picking different tooling) if folks found something that was a better fit. That offer still stands.
It looks like ANTLR supports re-using and extending grammars in a variety of ways, including the sclang grammar I just finished. ANTLR doesn’t generate sclang parsers (yet), and teaching ANTLR to generate sclang isn’t a high priority for me right now, but contributions welcome! If you’d like to help, please do get in touch.
Thanks for the correction, very much appreciated. I think(?) this is one of those where it was in the back of my mind that the project could be extended down the road, but then I didn’t write it 
so I gave a wrong impression of it.
I’d like to contact you by PM; your Sparkler is relevant to some writing that I’m finishing up. A bit later today, I think.
A generated parser in sclang would be of significant benefit for the preprocessor. I’ve written a parser in sclang (not for sclang code, for custom pattern expressions) – after some time, got to the point where I can maintain/extend it fairly straightforwardly, but I can’t say that it was easy. A lot of users who are interested in the preprocessor are likely to try it a bit, and then give up.
BTW, something funny, the antlr-mega-tutorial won’t allow you to read it online without giving them an e-mail address 
which… really…? Yeah. Pop-over that can’t be dismissed. Never mind then; that’s a sour taste. I might look for another tutorial at some point.
hjh