Turn few customizable options to variables

[geraldus]

Turn haskell-ghc-supported-extensions and
haskell-ghc-supported-options into variables, move them outside
customize package to haskell-mode one.

Related to #730

[ivan-m]

There is a possibility that someone might want these customised as a minimal subset that's supported by a range of GHC values (e.g. starts Emacs with ghc set to 7.10, at some point changes global settings so that /usr/bin/ghc points to 7.8 which has different supported extensions, etc.).

That said, I think the likelihood of this is minimal and unlikely to cause any problems. I thought it should just be mentioned as part of the risk-assessment of changing this behaviour.

[geraldus]

@gracjan don't merge this, I want to clarify doc strings a bit.

@ivan-m your statement sounds reasonable. Let me share my thoughts about this. If need to change some of these options I will do it imperatively rather than customizing these vars, because in the latter case my init file will grew up significantly as the list are too long, e.g.

(setq haskell-ghc-supported-extensions (delete "whatever" haskell-ghc-supported-extensions))

Also, currently these vars are only used in completion functions, and I suppose few wrong completions are not critical, as you mentioned already.

What about this: turn these options into vars and define two customizations, e.g. haskell-ghc-supported-extensions-override and haskell-ghc-supported-options-overrides, a lists containing items of form + option or - option. For example if you want to exclude RankNTypes and include OverloadedStrings from/in supported extensions you can customize haskell-ghc-supported-extensions-override to (list "+ RankNTypes" "- OverloadedString"). This is just example, we can provide some nicer way to customize this. I think this is easier to manage for user than a huge default list of values. To take this in account it is possible to write some helper functions, e.g. haskell-get-supported-extensions-list and haskell-get-supported-options-list.

[ivan-m]

That makes sense to me.

[geraldus]

@gracjan what do you think?
@ivan-m thank you, there is no much feedback on issues currently.

[gracjan]

The proposed machinery requires a lot of effort that could be spend elsewhere. Just imagine the amount of tests you would need to write to make sure it works as expected and the amount of documentation explaining what is going on.

I'm afraid I will not be able to agree to pull this complexity in for the sake of future haskell-mode contributors that will come after all of us three have moved on.

[geraldus]

@gracjan, so if I update doc string will you merge this?

[gracjan]

Yes.

[geraldus]

@gracjan updated

[gracjan]

Baah. One more thing to check: does structured-haskell-mode work if you moved those variables? It might do (require 'haskell-customize) and there it can fail.

(Somebody asked what is a submarine dependency. Well, this is one example).

[gracjan]

Okay, I've checked this and no issues with shm. Lets proceed.