> This is just a parser change so should be easy for all tools to support. I have nothing against changing the grammar, but I would never say it's "just a pars

> This is just a parser change so should be easy for all tools to support. I have nothing against changing the grammar, but I would never say it's "just a parser change". Haskell has no standard parser/AST/pretty-printer (e.g. like read/write for Lisp, or even "eval" in dynamic languages), so the only "portable" way of representing Haskell code is using raw strings, and cobbling together parsers, pretty-printers (or, heaven forbid, regexps) as required by the situation. With so many string-of-Haskell transformers around, changing the grammar is bound to require lots of work for tool and library makers. The de facto parser for Haskell is the one used by GHC, since almost all Haskell code is written solely for compilation by GHC with no regard for other parsers. Unfortunately, it's very hard to reuse components of GHC for anything other than compiling code. GHC does offer an API for invoking its parser, type-checker, etc. but it will crash (saying "the impossible happened") unless it's configured just right for that piece of code (setting "DynFlags", include directories, extensions, package databases, etc.). In practice, the only way to set those options correctly is to use the author's Cabal file, which limits us to either invoking the monolithic "ghc" command and hoping it has an option for what we need, or having our code pass all of those Cabal-provided commandline options to the GHC API, at which point we're basically reimplementing the "ghc" command. There are other parsers, like haskell-src-exts, TemplateHaskell quasiquotation grammars, etc. but they either require per-input configuration (which we can only get from Cabal files, which are tailored to GHC's particular options), or else they flat out fail for a large proportion of existing code (e.g. due to preprocessors like CPP). I ran into this myself when trying to make a tool for extracting ASTs of Haskell functions. In the end I went down the "hope ghc has an option" path, and wrote a Core-to-Core optimisation plugin to spit ASTs on to stderr. This is unfortunate since the ASTs are of GHC Core rather than Haskell, and it's very inefficient since it's running parts of the compilation pipeline which are completely unnecessary :(