Integrate haskell-flycheck into haskell-mode

[lukehoersten]

haskell-flycheck it's @chrisdone's flycheck implementation that uses a haskell-process as the backend.

Flycheck comes with a built-in flycheck-haskell that uses GHC. The Flycheck author, @lunaryorn, has the policy of not having Flycheck depend on external modes as it's untenable. Since haskell-flycheck is dependent on haskell-process within haskell-mode anyway, I think it makes sense to include @chrisdone's haskell-flycheck in this mode.

I'd be open to making the code changes myself and submitting a PR but I'm not sure the best approach to integrating something like this, especially since it's conditional on the availability of Flycheck.

[swsnr]

This was already discussed somewhere else (can't remember where, currently), and basically I won't merge any of @chrisdone's code unless he agrees personally—that's just a matter of fairness, imho—, and I won't merge it, if I have to maintain it on my own. It's too complicated for that, and I don't know Haskell Mode well enough, nor do I have the time to get to know it.

IOW, I'll only merge this checker, if @chrisdone agrees, and if he or someone else other than me agrees to maintain this checker as part of this repository.

[lukehoersten]

We discussed in a haskell-flycheck issue previously.

We don't have to merge it into flychecker. That was just one option. The other option is going into haskell-mode which I think we agreed on in our previous discussions. That works nicely because it keeps all the haskell-process stuff together.

Either way I want it to turn into something easy enough for people to get that it starts getting wider adoption. That's my whole goal here.

[swsnr]

@lukehoersten Oh sorry, there's apparently a misunderstanding. flycheck-haskell is not built-in. It's a Flycheck extension, which isn't subject to any policies about Flycheck itself.

As a matter of fact, flycheck-haskell already depends on Haskell Mode already, albeit only for some minor stuff.

I understand, that you'd like to have a haskell-process based checker published, but the fact that @chrisdone hasn't published it yet makes me think that it's probably not ready yet for a public release.

Anyhow, I'm not at all opposed to merging everything in flycheck-haskell, as long as @chrisdone agrees, and someone else other than me actually maintains the checker.

[lukehoersten]

I do think it makes sense to preserve the current checker as an option (maybe even the default option) as well. I'm not so concerned with where the package goes, just as long as it's reachable form package.el.

[swsnr]

@lukehoersten The current checker will stay anyway, since it's part of Flycheck itself, and still has a purpose, e.g. for small haskell sources, which don't have a cabal file. Flycheck Haskell currently just parses Cabal files and sets up Flycheck accordingly. It doesn't have any checkers on its own.

But again, the decision whether to make the haskell-process based checker available via package.el is not ours.

[lukehoersten]

• "IOW, I'll only merge this checker, if @chrisdone agrees"
• "Anyhow, I'm not at all opposed to merging everything in flycheck-haskell, as long as @chrisdone agrees,"
• "But again, the decision whether to make the haskell-process based checker available via package.el is not ours."

Be patient and give him a chance to respond. To be clear: I'm not disputing that the decision to merge is up to @chrisdone.

In the mean time, I don't want to confuse the discussion about how we would integrate the checkers with whether @chrisdone is OK with it. @chrisdone has mentioned earlier that integration specifics is his main concern:

chrisdone commented on Feb 5
I'm okay with merging this into flycheck-haskell if it unifies a common thing and avoids confusion. I'm concerned about pissing off your users by swapping out the backend with something that requires starting a session and ghci (things that people regularly complain about as being such a chore).

So this brings me back to my last point: how will this work? We have a few options:

1. Merge flycheck-haskell and haskell-flycheck into the flycheck-haskell package.el then auto-detect haskell-process if a session is started or just require the user to configure themselves.
2. Merge haskell-flycheck into haskell-mode to consolidate dependencies and default to the haskell-process checker.
3. Keep haskell-flycheck and flycheck-haskell separate package.el packages and the use of either would auto-enable the corresponding checker.

The focus here is on how does the user specify which checker should be used. If you're using haskell-process already, it seems unlikely the user would want to use a separate GHC process for flychecking.

[swsnr]

@lukehoersten In my opinion it makes no chance for us to discuss anything as long as he hasn't responded.

[lukehoersten]

From our previous discussion:

chrisdone commented on Feb 5
I'm okay with merging this into flycheck-haskell if it unifies a common thing and avoids confusion. I'm concerned about pissing off your users by swapping out the backend with something that requires starting a session and ghci (things that people regularly complain about as being such a chore).

[swsnr]

@lukehoersten I read “concerned” first, whereas you apparently read “I'm okay” :)

But I guess we can take that as agreement of @chrisdone, so please feel free (you or @chrisdone, whoever wants) to open a pull request that adds his Cabal Repl checker to this repository. If @chrisdone wants, I can give him write access, but I'd like to review the checker before merging it into this package and thus released it to a greater audience.

If another way of integration is desired, e.g. moving everything into Haskell Mode or so, please tell me. I don't cling to this repo, so if you see a better place for this code, I'd be ok to move it somewhere else.

[lukehoersten]

@lunaryorn, Chris is concerned about changing the default checker but he's OK with merging the packages.

Preserving the default means we need to work out the technical details about how the two checkers will interact and become enabled. Until the technical details are worked out, we will not merge anything. Unless you are ready to contribute to this technical discussion I'm afraid we're stalled.

[gracjan]

@lunaryorn: I know that you were in the middle of rewrite of generalized checker. How far are you with this?

Currently haskell-mode has a lot of ways to check Haskell code, including the new ide-backend. There is quite a lot of cleanup needed in haskell-mode before we can handle yet one checker.

@lukehoersten: I knew that flychecker-haskell uses haskell-cabal.el for a reason but I did not know that it uses haskell-process.el for anything. How does it use it?

[gracjan]

Note that we still have remnants of flymake in the code, those are reported to not always work as in #384 or #130.

[lukehoersten]

@gracjan:

• haskell-flycheck is @chrisdone's haskell-process-based checker.
• flycheck-haskell is @lunaryorn's cabal-integration package for the ghc-checker built into flycheck. He'd have to provide any more details beyond that.

I don't believe that haskell-flycheck depends on anything but haskell-mode (for haskell-process) and flycheck. haskell-process is what it uses for cabal integration (via ghci etc).

My comment above enumerates some of the possibilities and potential tradeoffs of merging haskell-flycheck into haskell-mode (because of it's haskell-process dep) or lumping it in with the flycheck-haskell package as just sort of an "extras" package for haskell emacs flycheck stuff.

My personal preference is to merge haskell-flycheck into the flycheck-haskell package and then just give users a way to switch over the haskell-process-checker if they're using haskell-process already or something like that (the mechanics still need to be worked out). We'd leave the default as the ghc-checker in this case.

[gracjan]

I did not know that haskell-flycheck is something different than flycheck-haskell. It that case at least half of my comment does not apply :)

[lukehoersten]

In hind sight haskell-flycheck should really be called flycheck-haskell-process and flycheck-haskell should be called flycheck-haskell-cabal or something like that. flycheck proper already has a checker called ghc-checker. This ambiguity is exactly what I'm trying to resolve here while simultaneously simplifying configuration and access to these projects.

NOTE: I'm not really proposing those name changes, just using them for illustrative purposes.