Hi
I'm not entirely sure what the intended audience is for this simple AST. Unless someone's going to use it, I don't see much point in it existing.
When you just use the AST, you can ignore the bits that you don't need. But when you need to transform it, there is no way to ignore parts of it. And that creates a huge amount of extra work and boilerplate code with the current feature-loaded AST.
If you aren't using a boilerplate removal library, and are working with haskell-src-exts, then you are very probably doing it wrong! I recommend Uniplate, but there are plenty of other options including SYB and anything with the phrase generic and Haskell in it from the last 15 years. I really cannot stress how much difference a boilerplate removal library makes. I'd also love a "Core Haskell" library, like HSE but with desugaring/type-checking/name-resolution etc. That's not what HSE does, but it is a niche that needs filling.
In addition, a high-quality parser whose AST more faithfully reflects the Haskell 20nn standard is very useful in many ways in the area of verification, validation, and certification.
Making a parser faithfully reflect the standard is not a trivial proposition, and one that I don't think anyone is actually going to check. A parser that kinda-might reflect the standard doesn't help with verification/validation/certification.
If people are absolutely keen on getting haskell-src-exts into the platform immediately with its new name, another strategy could be to rename haskell-src to haskell98-src and haskell-src-exts to haskell-src.
I always talk about HSE, so if the name changes I'll need a new acronym, and HS doesn't sound like a great choice :-) I'm happy with any name, and I don't really have an opinion about including HSE or not (it's awesome, but it being in the platform doesn't really benefit me massively, as it's so easy to install with cabal). All I care about is Niklas not using up his valuable time on a project that doesn't pay off for users. Thanks, Neil