[Haskell-cafe] On Haskell IDEs

[Andrey Chudnov]

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?

/Andrey

On 03/10/2014 05:11 PM, Michal Antkiewicz wrote:
> Cabal repl is absolutely great! Are there any reasons why it couldn't 
> provide all information that ghc-mod and hdevtools do? It could be run 
> as a background process, right? It knows about sandboxes as well.
>
> That would be a great SoC project - extend cabal repls to subsume 
> ghc-mod and hdevtools.
>
> Michal
>
>
> On Mon, Mar 10, 2014 at 4:59 PM, Andrey Chudnov <achudnov at gmail.com 
> <mailto:achudnov at gmail.com>> wrote:
>
>     While I do not condone Mr. Verdi's verbal bashing of the efforts
>     of the Haskell community to provide development tools, I do feel
>     his pain. There is quite a bit of divided effort which seems to
>     result in having multiple inferior solutions.
>
>     My all-time favorite is ghc-mod because "it just works", but it
>     can be very slow for large projects, especially involving
>     template-haskell (and there are no easy fixes for that).
>
>     HDevTools, in theory, is great: a persistent server, allowing
>     incremental builds/checks etc., but it's oblivious to .cabal
>     files, let alone sandboxes, which makes it completely impractical
>     for any degree of serious Haskell development (on that note, how
>     come pull request 30 [1] is still open?! /rant).
>
>     Finally, GHCi is supposed to be enough for IDE support in editors.
>     However, as I understand it, the problem is that its output is not
>     easily parsed and, hence, consumed by editors; on top of that,
>     using it with .cabal files and sandboxes requires calling 'cabal
>     repl', so using another tool.
>
>     So, maybe, GHCi could be augmented with an easily consumed output
>     format (like JSON), and 'cabal' be given support for that mode as
>     well? Since it's that time of the year again (I mean, the GSoC
>     proposal time :)), maybe, someone would look into this idea?
>
>     [1] https://github.com/bitc/hdevtools/pull/30
>
>     /Andrey
>
>
>     On 03/10/2014 03:44 PM, Vagif Verdi wrote:
>>     Sorry, i meant ghci not cabal.
>>
>>     As for hsdev, in order to provide its features it will have to
>>     load and keep track of entire project information which is
>>     already done by ghc-mod and hdevtools separately. So you ushould
>>     see how much effort is wasted on doing the same thing again and
>>     again in each of 4 different tools (ghci, ghc-mod, hdevtools and
>>     hsdev)
>>
>>     On Monday, March 10, 2014 12:32:25 PM UTC-7, Niklas Hambüchen wrote:
>>
>>         On 10/03/14 18:41, Vagif Verdi wrote:
>>         > This is an excellent illustration of how fragmentation in
>>         this specific
>>         > area hurts community. Not only you are forced to use 3
>>         different tools
>>         > (ghc-mod, hdevtools, cabal) each of which basically
>>         provides the same
>>         > service but in an incompatible and incomplete way. But you
>>         decided to
>>         > create yet another one instead of contributing to the ones
>>         you already
>>         > use (they are all open source)
>>
>>         I'm not sure what you mean to say; ghc-mod and cabal
>>         certainly do not do
>>         the same. Hsdev doesn't either, and claiming that we don't
>>         contribute to
>>         these projects is strange.
>>         _______________________________________________
>>         Haskell-Cafe mailing list
>>         Haskel... at haskell.org
>>         http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>>     _______________________________________________
>>     Haskell-Cafe mailing list
>>     Haskell-Cafe at haskell.org  <mailto:Haskell-Cafe at haskell.org>
>>     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto: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/20140310/8d94d2f3/attachment.html>