[Haskell-cafe] On Haskell IDEs

[AlanKim Zimmerman]

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/8b5ed446/attachment.html>