[Discussion] Separation of concerns

[geraldus]

Hi everybody!

Should we simplify haskell-mode to just syntax highlight and indentation machinery (with some auto completion tweaks), and move all heavy interactive logic to another one package, including error highlighting (since it is related on compilation too), REPL completions, type information, etc.?

What do you think?

[ivan-m]

I'm not sure that's such a great idea, as some of the interactive logic (e.g. the new haskell-interactive stuff Chris Done added) seems to be relatively integrated together, so I'm not sure how well it would work split up into various packages.

That said, I just use haskell-mode and don't contribute to it much :)

[gracjan]

I've added a 'discussion' label here so that we know this 'issue' is a forum thread to discuss possible ways forward.

We have done splitting of haskell-mode already before, see for example haskell-yas project that used to be part of haskell mode and no longer is.

It was easy to split as the internal dependencies were not tight.

I would say that we need to do a lot of internal cleanup and untangling so that we are able to split when we need.

I would love if contributors concentrated more on font-lock and indentation. Historically though most contributions come to interactive parts of haskell-mode.

[bergey]

I'd really like to be able to tell new Haskellers (who use emacs) that there's one package to install, which has most of the useful features and acceptable defaults. I worry that if haskell-mode doesn't take that role, we'll return to outdated blog posts describing how to set things up.

I think splitting things up would make it harder to communicate what to install, and harder to make things just work, especially since so many people run HEAD via Melpa.

I think there's still lots of low-hanging fruit to simplify haskell-mode by removing duplication, without splitting out widely used features. That should also make it easier to contribute.

[mgsloan]

I heartily agree with splitting things out and simplifying haskell-mode. As someone who's still rather quite inexperienced with elisp, customizing and contributing to haskell-mode is daunting due to its size. As @bergey points out, having multiple ways to achieve similar results is also something that contributes to this.

One issue is whether this'd be done in a way that doesn't break people's configurations. What if the syntax highlighting and indentation machinery got turned into haskell-mode-core (the actual mode name would still be haskell-mode). Then, the main interaction stuff could go in haskell-mode-interactive or something. haskell-mode would provide these, along with any deprecated components.

This way, there'd be a smaller and more easily understood elisp package for haskell, haskell-mode-core, which can be used as a base for new interactive modes (such as one for haskell-ide-engine).

[gracjan]

We are working on removing redundancy and all the more convoluted components. HIE should take quite some complexity away.

Hackability comes from a comprehensive test suite and we are in the process of creating one. There are already 232 tests, the functionality that is covered can be easy to hack even by relativelly inexperienced person.

[mgsloan]

Great, thanks for your efforts, @gracjan !

[gracjan]

Seems like the discussion dried out. Lets agree on the following:

1. If somebody comes along and will want to take over maintenance of components in separate way, we will be okay with that.
2. We will try to not let more complexity inside haskell-mode.
3. We will reduce complexity and duplication of what is already there.
4. Overall we will try to reduce barrier to entry for new contributors by writing good code, test suite and documentation.