Open dramforever opened 4 years ago
What kind of machine readable output would you like? I dont know enough about #71 to know whether its implementation would be feasible for this project.
I'm not sure about the format, but I think the goal is to have non-Haskell code be able to build on top of hie-bios just like hie builds on top of hie-bios. A possibility, for example, is for vscode-ghc-simple, a JavaScript program, to be able to call hie-bios
as a subprocess, obtain its output in JSON, and use that to know how to start GHC for the project.
The easiest output format might be a JSON dump of whatever you send to the 'upper layers'. But I do see usage of functions, so maybe that will be a problem.
I've just learned about hie-bios and I'm very glad about it, but I have a lot to learn ahead.
I second this feature request by @dramforever. It would be nice to call hie-bios
for a list of modules, like this:
hie-bios flags --json-output Foo.Bar Test.Module
and have the following content in stdout
:
[
{ "module": "Foo.Bar"
, "flags": ["-XLambdaCase", "-XDataKinds", "..." ]
},
{ "module": "Test.Module"
, "flags": ["-fno-warn-orphan-instance", "..." ]
}
]
This would be a good feature to have, so that it is easier to get the likes of the vim plugin ale
to pick up the correct current ghc configuration flags and project root directory.
It might help if hie-bios could produce machine-readable information about environments. For example, it could dump the flags it got into JSON and print that to stdout. This way non-Haskell projects like vscode-ghc-simple can benefit from this project.
The CLI seems to be debugging-oriented at the moment, which means that it doesn't separate the use of stderr/stdout very clearly. This should also be fixed if the output is ever piped into another program.
Related: #71