[Haskell-cafe] On Haskell IDEs

[Carlo Hamalainen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140311/a20f40cf/attachment.html>