> Note that even GHC can't re-use its own ASTs: the Template Haskell extension provides its own AST representation, entirely separate to that used by the compiler's frontend!
Isn't that about the expression problem, though? How would changing the syntax help?
s-expressions are already (a trivially deserialised encoding of) an AST representation. If the Haskell language used s-expressions, or if the "frontend" language was designed to desugar into s-expressions via a standalone pre-processor, then this representation would be available to any code that wanted to use it. Different programs, or different parts of the same program, might decide to convert it to their own specialised datatypes (like those of GHC's frontend and Template Haskell), but those would essentially be details specific to that program (either as an implementation detail or an API). It would have no real influence on how others choose to process the language.
If we think of the current GHC implementation in this way, we find that the only de facto representations of Haskell code is `ByteString` (or `Lazy.ByteString` or `String` or `Text` or `Lazy.Text`, of course ;) ). Since these are generally unparseable (e.g. via haskell-src-exts and friends), it's hard to do much with them (hence the tendency to delve into GHC's own representations).
Note that for my own work I ended up abandoning Haskell syntax altogether in favour of GHC Core. I use Cabal and GHC to do the parsing (since that seems to be the only way to handle real world code), and a GHC plugin to dump out Core as s-expressions http://chriswarbo.net/git/ast-plugin
Isn't that about the expression problem, though? How would changing the syntax help?