Turn haskell-ghc-supported-extensions and haskell-ghc-supported-options customization options to variables

[geraldus]

I can't be certain, but haskell-ghc-supported-extensions¹ and haskell-ghc-supported-options² are likely useless, when you try unfold them it brings a huge list. I can't imagine the case when it needed to extend these lists, or remove/modify items. In both cases values are fetched by invoking shell commands (ghc --show-options and ghc --supported-extensions). I think it's better to modify these options to variables.

[ivan-m]

I know that shm uses ghc --supported-languages (which is a alias for ghc --supported-extensions) to complete LANGUAGE pragmas; possibly something similar could be done in haskell-mode itself?

(haskell-ghc-supported-options could then be used to help auto-complete fields in .cabal files...)

[geraldus]

It's very strange to me, that we have following code¹ in haskell-customize.el:

(defcustom haskell-language-extensions
  '()
  "Language extensions in use. Should be in format: -XFoo, -XNoFoo etc."
  :group 'shm
  :type '(repeat 'string))

Should it be moved to SHM itself? @ivan-m are you talking about this? In my Emacs installation it's empty (as default value).

Looks like SHM get extensions from Language.Haskell.Extensions² using its binary³.

@chrisdone can you clarify a bit?

[ivan-m]

Looks like something that wasn't moved over to shm properly.

Though I was referring to this usage by shm (which doesn't use its own binary, nor get them from Cabal); what you linked to I believe is for parsing purposes.

[chrisdone]

Oh, this variable has the wrong group, that's all. The idea is that various tools written with HSE that don't know what extensions to use can use this variable. Examples: hlint, hindent, structured-haskell-mode, tool-de-jour, …

[geraldus]

@chrisdone, I guess in this case the group should be haskell.

BTW, you can use mentioned haskell-ghc-supported-extensions variable here. Also I will introduce similar variable for pragma names in haskell-mode in my next PR related to completions stuff, so you will be able to use it and remove this variable from SHM. I can ping you when it will be done or provide a PR.

[chrisdone]

BTW, you can use mentioned haskell-ghc-supported-extensions

Nooo. I think that is different. We have the two cases:

• haskell-ghc-supported-extensions: here are all extensions that GHC _supports_
• haskell-language-extensions: here are the extensions that are enabled in this buffer(s)

I want to be clear that those are different before you make any changes. :-)

[geraldus]

@chrisdone hmm, why not?

haskell-ghc-supported-extensions value is set by¹

(split-string (shell-command-to-string "ghc --supported-extensions"))

SHM uses²:

(split-string (shell-command-to-string "ghc --supported-languages")

And ghc --supported-languages is an alias for ghc --supported-extensions and gives same results, so the result should be the same in both cases. Am I missing something?

[chrisdone]

Yes, those two are the same. As long as you're leaving haskell-language-extensions alone, your plan seems good. 👍

[gracjan]

Such submarine dependencies are very fragile invisible constructs. Other Emacs packages tend to depend on obscure functions and variables. Recently we had such a problem with ghc-mod.

haskell-language-extensions is never mentioned anywhere else in haskell-mode. This is questionable and fragile engineering that puts unnecessary ambush surprises on future coming new contributors.

[chrisdone]

It's the same kind of variable as haskell-indent-spaces.

If you have anything cogent to contribute, please do so. Name-calling things "questionable" and "fragile" is zilch.

[gracjan]

@chrisdone: Please follow https://help.github.com/articles/using-pull-requests/ even you have commit bit. We try to get all changes through TravisCI before they are merged.

Your added comment forgets to explain if nil as value means no extensions or all available extensions.

[chrisdone]

"Forgets" is the wrong word, it implies there was ever any intention to write about this strange notion of "all available extensions", as if they're all mutually compatible, to begin with, which there neither was nor is.

[gracjan]

So I had to go to the place where this variable is used to find out what is the meaning of haskell-language-extensions.

Here is what happens:

-- | Default extensions.
defaultExtensions :: [Extension]
defaultExtensions =
  [e | e@EnableExtension{} <- knownExtensions] \\
  map EnableExtension badExtensions

-- | Extensions which steal too much syntax.
badExtensions :: [KnownExtension]
badExtensions =
    [Arrows -- steals proc
    ,TransformListComp -- steals the group keyword
    ,XmlSyntax, RegularPatterns -- steals a-b
    ,UnboxedTuples -- breaks (#) lens operator
    -- ,QuasiQuotes -- breaks [x| ...], making whitespace free list comps break
    ]

https://github.com/chrisdone/structured-haskell-mode/blob/master/src/Main.hs#L280

So shm enables all available extensions (in haskell-src-exts) minus some deemed bad.

@chrisdone: Please write some ERT tests for this variable instead of arguing.

[chrisdone]

The particular behaviour of SHM, one consumer of this variable, is irrelevant, what it does with the list may change at any time. The variable's purpose has been documented.

@chrisdone: Please write some ERT tests for this variable instead of arguing.

Stop pinging me by name on this issue. I'm done here.