[Haskell-cafe] On Haskell IDEs

[Maxim Kulkin]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140311/6b81a6bc/attachment.html>