[Haskell-cafe] On Haskell IDEs

[Maxim Kulkin]

I played a bit with GHC API and Cabal (and even implemented .cabal support
for hdevtools) and now I see issues with this approach:

1. GHC depends on Cabal (rly?) and this is most likely some old version of
Cabal, not the one you use currently (e.g. I use cabal-install and Cabal
1.18, but GHC 7.6.3 -- the latest stable -- depends on Cabal 1.16). This
makes it hard to develop tools that both use GHC API and latest Cabal.
Hopefully this dependency will be removed in future versions of GHC.

2. Sometimes you get stuck with types and can't get source code compile and
GHC API-based tools are of no help in this situation, because they won't be
able to provide type for some variable in source file because this source
file contains a syntax/type error in some other part. I'm not sure if GHC
API can be tweaked to bypass errors and do the best effort of
parsing/desugaring of other parts of sources with errors. Maybe some
external parser (haskell-src-exts) should be used for source inspection.


On Tue, Mar 11, 2014 at 10:25 AM, Carlo Hamalainen <
carlo at carlo-hamalainen.net> wrote:

>  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 Hamalainenhttp://carlo-hamalainen.net
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140311/003e4fba/attachment.html>