[Haskell-cafe] On Haskell IDEs

Tue Mar 11 08:20:55 UTC 2014

Unifying all the different tools underlying IDEs has been talked again
before, because the pain is real. For example, see
https://github.com/fpco/haskell-ide/wiki. I've written about the GHC API in
that wiki, and some of the issues that it has for such tools.
Currently EclipseFP uses buildwrapper, which is a backend I wrote because I
was dissatisfied with scion. It integrates the GHC API and Cabal, so that
it aims to give the same results that running cabal configure/build. It
usually run as a shortlived executable but for performance reason it is
possible to have a long lived session to avoid reloading the modules in GHC
all the times.
Yes, GHC depends on the Cabal API for some types, which causes untold woes
when you use buildwrapper after upgrading Cabal, for example. There is a
bug report to remove that dependency but I had no time yet to work on it,
so far I've used dynamic-cabal in buildwrapper to allow a newer version of
Cabal, at the price of more complexity. But a complete tool would need to
integrate both, so it can't be ghci only, otherwise Cabal and GHC would
become really stuck together.
The GHC API uses some global settings, which means you sometimes have no
choice (if stcouldatic flags change) than to respawn a new process. This
could probably be improved since it's not really the way a well behaved
Haskell program should act. Memory usage is also a concern.

So I think there should be two lines of work here: one would be to improve
the GHC API and/or the ghci interface, to make it more IDE friendly, the
other would be to unify all these tools like scion/buildwrapper/ghc-mod in
one tool that would hopefully provide all services an IDE needs, and that
would allow easy plugin of additional functionality (so for example HaRe
could easily add its refactoring capabilities to it). I would happily
switch from buildwrapper to another community supported tool if all the
functionality I currently have is kept in one form or another.

JP

On Tue, Mar 11, 2014 at 9:17 AM, Maxim Kulkin <maxim.kulkin at gmail.com>wrote:

> The thing is not with types: I would like to use a version of cabal in my
> tool, but dependency on GHC API (which I also use) dictates me other
> (older) version of Cabal for an unknown and unobvious reason. I want user
> of my tool to pick arbitrary Cabal version, the one that he actually uses.
> I'm even ok to write different implementations to support differencies in
> Cabal API.
>
> I once googled a mailing discussion on that GHC uses methods for parsing
> and printing some types like package ids or something and they introduced a
> dependency for that reason.
>
>
>
> On Tue, Mar 11, 2014 at 12:08 PM, AlanKim Zimmerman <alan.zimm at gmail.com>wrote:
>
>> HaRe gets around the cabal version mismatch by making sure that the
>> return types from the relevant ghc-mod calls are types that are not
>> exported by cabal.
>>
>> e.g.
>> http://hackage.haskell.org/package/ghc-mod-3.1.4/docs/Language-Haskell-GhcMod-Internal.html#v:cabalAllTargetsreturns [String] for the target names.
>>
>> This could perhaps be extended to either use a separate library of stable
>> types to be used by both cabal and ghc, or to return e.g. json
>>
>> Alan
>>
>>
>> On Tue, Mar 11, 2014 at 9:19 AM, Maxim Kulkin <maxim.kulkin at gmail.com>wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

-- 
JP Moresmau
http://jpmoresmau.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140311/462a227d/attachment.html>