Skip to content
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

Closed
geraldus opened this issue Jun 18, 2015 · 19 comments

Comments

@geraldus
Copy link
Contributor

I can't be certain, but haskell-ghc-supported-extensions1 and haskell-ghc-supported-options2 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
Copy link
Contributor

ivan-m commented Jun 19, 2015

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
Copy link
Contributor Author

It's very strange to me, that we have following code1 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.Extensions2 using its binary3.

@chrisdone can you clarify a bit?

@ivan-m
Copy link
Contributor

ivan-m commented Jun 19, 2015

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
Copy link
Member

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
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Contributor Author

@chrisdone hmm, why not?

haskell-ghc-supported-extensions value is set by1

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

SHM uses2:

(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
Copy link
Member

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

@gracjan
Copy link
Contributor

gracjan commented Jun 19, 2015

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
Copy link
Member

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
Copy link
Contributor

gracjan commented Jun 19, 2015

@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
Copy link
Member

"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
Copy link
Contributor

gracjan commented Jun 19, 2015

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
Copy link
Member

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.

@ivan-m
Copy link
Contributor

ivan-m commented Jun 20, 2015

@gracjan except that bit of code is not what was being talked about; @geraldus was asking about the elisp variables in haskell-mode and I said that one of them could be used for similar functionality to something that SHM has in elisp.

@gracjan
Copy link
Contributor

gracjan commented Jun 20, 2015

@ivan-m: I agree with your comments.

For reference haskell-language-extenstions is used in exactly two places in shm:

(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.

@gracjan
Copy link
Contributor

gracjan commented Jun 20, 2015

@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.

@geraldus
Copy link
Contributor Author

@gracjan surely

@ivan-m
Copy link
Contributor

ivan-m commented Jun 20, 2015

@gracjan what do you mean by submarine dependencies?

Note that haskell-language-extensions is not what @geraldus was referring to originally; IIUC this variable is equivalent to having language extensions specified in the .cabal file (and using ghci rather than cabal-repl) rather than using LANGUAGE pragmas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants