Ben Millwood wrote:
But if we make the official parser usable for AST manipulation, we have to rule on the design issues I raised above: whether to make efforts to stop invalid lambdas being constructed, how to name the types and constructors, etc.
No we don't. With regard to its inclusion as part of the standard, we make only one guarantee - that it serves to verify whether code is compliant to the standard. For your convenience, the package maintainer will try to make it useful for other things too, but in that respect it is no different than any other package on Hackage.
What purpose does it serve that a Haskell parser independent of the report does not?
Machine verification of Haskell 20nn standards compliance.
We can't guarantee it's bug-free
We can't guarantee that the human-readable part of the standard is bug-free, either. It always has had bugs and it always will, like any standard. We do the best we can. Actually, there is the possibility of developing an automated system to generate unit tests from the standards document to verify the consistency of the parser with the document. Those same unit tests could then also be used by compiler writers to certify the compliance of their Haskell 20nn mode and do regression testing. There are many intriguing possibilities.
I suppose providing a reference parser at least ensures that any modification to Haskell syntax is implementable, and the issues in its implementation will have been considered
Yes that is one of the advantages of this approach.
but in practice every alteration to the Haskell language from now on is going to be standardising extensions that already exist, so I don't really think this is a priority.
For you it may not be a priority. But for enterprise project architects who are required to consider and document every possible risk before agreeing to adopt Haskell, it is a priority. Regards, Yitz