New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Turn haskell-ghc-supported-extensions and haskell-ghc-supported-options customization options to variables #730
Comments
I know that shm uses ( |
It's very strange to me, that we have following code1 in (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 @chrisdone can you clarify a bit? |
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. |
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, … |
@chrisdone, I guess in this case the group should be BTW, you can use mentioned |
Nooo. I think that is different. We have the two cases:
I want to be clear that those are different before you make any changes. :-) |
@chrisdone hmm, why not?
(split-string (shell-command-to-string "ghc --supported-extensions")) SHM uses2: (split-string (shell-command-to-string "ghc --supported-languages") And |
Yes, those two are the same. As long as you're leaving |
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
|
It's the same kind of variable as If you have anything cogent to contribute, please do so. Name-calling things "questionable" and "fragile" is zilch. |
@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 |
"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. |
So I had to go to the place where this variable is used to find out what is the meaning of 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. |
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.
Stop pinging me by name on this issue. I'm done here. |
@ivan-m: I agree with your comments. For reference (defcustom shm-language-extensions
(if (boundp 'haskell-language-extensions)
haskell-language-extensions
'())
"Language extensions in use. Should be in format: -XFoo, -XNoFoo etc."
:group 'shm
:type '(repeat 'string))
(defun shm-language-extensions ()
"Get the number of spaces to indent."
(if (boundp 'haskell-language-extensions)
haskell-language-extensions
shm-language-extensions)) I'm still bothered by unused variables, I'm still bothered by submarine dependencies, I'm still bothered by new contributors hitting such obstacles. |
@geraldus: Can you restate exactly what was your intention in the beginning with certain terms in a new PR request? I would like to mark it as well-defined-task, for that it has to sound as a simple description what should be done. |
@gracjan surely |
@gracjan what do you mean by submarine dependencies? Note that |
I can't be certain, but
haskell-ghc-supported-extensions
1 andhaskell-ghc-supported-options
2 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
andghc --supported-extensions
). I think it's better to modify these options to variables.The text was updated successfully, but these errors were encountered: