Hello, it seems pretty reasonable to change it, but we should change the version number as well (well, and add it if it is not there). In general, having a version number is probably good practice for any outward facing machine readable format. -Iavor
On Fri, Jan 29, 2021 at 11:51 AM Ben Gamari <b...@well-typed.com> wrote: > Richard Eisenberg <r...@richarde.dev> writes: > > > Hi devs, > > > > In my work with Alfredo at revising our error message infrastructure, > > we ran across some code that renders error messages as JSON. Given > > that our data structures are changing, it seems natural to change the > > JSON output, too, but it's unclear whether that's wise. The manual > > currently lists -ddump-json in the chapter on "Debugging the > > compiler", suggesting that a change is fine, but I'm not yet > > convinced. > > > I think it would be fine to change the output. However, note that there > is a reason why this flag is in the -d flag namespace and the "Debugging > the compiler". The output is quite unstructured and we reserve the right to > change the representation, largely because it was hard to do better > without first fixing #8809. > > After we have the new rich errors infrastucture in place I think we will > be in a much better place to discuss a properly-supported flag (via the > proposal process, presumably). However, I think when we do so we should > be careful to constrain the scope of the provided output. GHC is not a > language server and I don't think it would be wise to make it one. > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
