On 10/03/14 22:22, Andrey Chudnov
wrote:
If we go down that road, it's not cabal-repl that would need to be
extended. AFAIK, it's just a wrapper around GHCi that calls that
latter with package info extracted from the cabal file and,
optionally, the sandbox. So, really, it's GHCi that would need to
be extended. I think, something as simple as adding an option to
output JSON (or some other structured format with wide support in
editors) instead of plain text would go a long way to allow
editors to consume it's output: they could just pipe commands via
stdin and read the JSON output via stdout, parse it and display
the info in the buffer. Depending on how GHCi looks inside and how
amenable it is to such modifications, it might actually be a
doable summer project. Am I missing any technical gotchas?
Regarding the data format, ghc-mod uses the GHC API to get the
de-sugared and type-checked representation of a module, e.g.
https://github.com/kazu-yamamoto/ghc-mod/blob/master/Language/Haskell/GhcMod/Gap.hs#L326-L337
Or, my tool ghc-imported-from needs to get the "guts" from the GHC
API to get the global reader environment:
https://github.com/carlohamalainen/ghc-imported-from/blob/master/Language/Haskell/GhcImportedFrom.hs#L343-L373
So my feeling is that we'd need to pass Haskell values back and
forth, not just JSON.
Personally I would love it if GHCi was extended in the way that you
are suggesting, as it would make my tool much faster. Ditto for
ghc-mod.
--
Carlo Hamalainen
http://carlo-hamalainen.net