refactoringtools / hare Goto Github PK

Originally https://github.com/alanz/HaRe/issues/21 by @atondwal

Built from master with

sh-4.2$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
sh-4.2$ cabal --version
cabal-install version 1.22.6.0
using version 1.22.4.0 of the Cabal library 

I run into:

sh-4.2$ ghc-hare help
"help" not supported

ghc-hare version 0.7.2.8
Usage:
         ghc-hare demote [-g GHC_opt1 -g GHC_opt2 ...] filename line col
         ghc-hare dupdef [-g GHC_opt1 -g GHC_opt2 ...] filename newname line col
         ghc-hare iftocase [-g GHC_opt1 -g GHC_opt2 ...] filename startline startcol endline endcol
         ghc-hare liftOneLevel [-g GHC_opt1 -g GHC_opt2 ...] filename line col
         ghc-hare liftToTopLevel [-g GHC_opt1 -g GHC_opt2 ...] filename line col
         ghc-hare rename [-g GHC_opt1 -g GHC_opt2 ...] filename newname line col
         ghc-hare help

  -m FILE    --mainfile=FILE  Main file name if not specified in cabal file
  -g ghcOpt  --ghcOpt=ghcOpt  GHC options
  -v         --verbose        debug logging on
  -b sep     --boundary=sep   specify line separator (default is Nul string)

and this is the case for any command I try.

Originally https://github.com/alanz/HaRe/issues/25

The elisp code should live on MELPA.

The current structure is not appropriate for this.

Re-arrange it so that it can live on MELPA

I wanted to try out hare from the command line and I have some "strange" results [22:46:53]
actually I tried "rename" and "addOneParam" on a very simple function, but all that happened is the function definition get duplicated [22:47:42]

@kmate, please provide details

I'm using haskell-ide-engine (commit cc71e5bd, and the version of HaRe that this depends on) with Sublime Text HST and when renaming the function name at this line with it to pooledMapConcurrently2, it modifies the file like so:

{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TupleSections #-}

module PooledMapConcurrently
pooledMapConcurrently2 :: (Traversable t, MonadIO m, Async.Forall (Async.Pure m), MonadBaseControl IO m) => (a -> m b) -> t a -> m (t b)
pooledMapConcurrently2 f xs = do
  , pooledMapConcurrently'
  ) where

import           Control.Concurrent.Async.Lifted (Concurrently(..))
import qualified Control.Concurrent.Async.Lifted.Safe as Async
import           Control.Concurrent.MVar.Lifted
import           Control.Monad.Trans
import           Control.Monad.Trans.Control
import           Data.IORef
import           Data.Foldable
import           Data.Traversable
import           GHC.Conc (getNumCapabilities)

  ( pooledMapConcurrently2
  numProcs <- liftIO getNumCapabilities
  pooledMapConcurrently' numProcs f xs

pooledMapConcurrently' :: forall t m a b . (Traversable t, MonadIO m, Async.Forall (Async.Pure m), MonadBaseControl IO m) => Int -> (a -> m b) -> t a -> m (t b)
pooledMapConcurrently' numThreads f xs = if numThreads < 1
 then error ("pooledMapConcurrently: numThreads < 1 (" ++ show numThreads ++ ")")
 else do

   jobs :: t (a, IORef b) <- liftIO $ for xs (\x -> (x, ) <$> newIORef (error "pooledMapConcurrently: empty IORef"))

   jobsVar :: MVar [(a, IORef b)] <- liftIO $ newMVar (toList jobs)

   runConcurrently $ for_ [1..numThreads] $ \_ -> Concurrently $ do
     let loop :: m ()
         loop = do
           m'job :: Maybe (a, IORef b) <- liftIO $ modifyMVar jobsVar $ \case
             [] -> return ([], Nothing)
             var : vars -> return (vars, Just var)
           for_ m'job $ \(x, outRef) -> do
             y <- f x
             liftIO $ atomicWriteIORef outRef y
             loop
     loop

   liftIO $ for jobs (\(_, outputRef) -> readIORef outputRef)

Note the broken exports list and the function losing its type signature and first line.

Was https://github.com/alanz/HaRe/issues/38

Before doing a refactoring the elisp checks for modified buffers. It should skip ones for dired.

f x = let (a, b) = (x, x) in a

liftToTopLevel-ing a results in

f x = (a x)

(a, b) = (x, x)

A simple fix is to refuse to lift such declarations, though it might be interesting to implement something less trivial in the future.

f x = a x
a x = fst (x, x)
b x = snd (x, x)

Originally https://github.com/alanz/HaRe/issues/26

Even for a small subset of it

Looks like HaRe has been abandoned. The last commit here is from 2017. There are no build plans for GHC > 8.0.
I made this fact explicit via revisions, e.g.: https://hackage.haskell.org/package/HaRe-0.8.4.1/revisions/

Maybe you want to make this explicit by archiving this repo or flagging the unmaintained status prominently in the README.

Is there any follow-up project? I am interested in a tool to find clones in Haskell code bases...

I am trying to get HaRe set up in emacs and when I try to rename a local variable it asks what new name I want to use, then prints something like this in the minibuffer:

[1 of 5]
RefSet

I tried running ghc-hare --version as the README suggets, and I get an error, but it does also show the version:

% ghc-hare --version
unrecognized option `--version'

ghc-hare version 0.8.2.1
Usage:
	 ghc-hare demote [-g GHC_opt1 -g GHC_opt2 ...] filename line col
	 ghc-hare dupdef [-g GHC_opt1 -g GHC_opt2 ...] filename newname line col
	 ghc-hare iftocase [-g GHC_opt1 -g GHC_opt2 ...] filename startline startcol endline endcol
	 ghc-hare liftOneLevel [-g GHC_opt1 -g GHC_opt2 ...] filename line col
	 ghc-hare liftToTopLevel [-g GHC_opt1 -g GHC_opt2 ...] filename line col
	 ghc-hare rename [-g GHC_opt1 -g GHC_opt2 ...] filename newname line col
	 ghc-hare help

  -v  --verbose  debug logging on

So I tried manually running it on a file and I get:

% ghc-hare rename src/Focus/Wheatley/DSL/Subs/BlobSearch.hs 29 39
(error "SafeList")

I searched for occurences of SafeList in the HaRe source but came up empty handed so I'm a bit stumped as to how to proceed.

Any guidance would be appreciated, as HaRe looks awesome!

Original https://github.com/alanz/HaRe/issues/37 by @wolftune

http://www.stackage.org/ has instructions, very very easy, just needs to be the actual package author opting in, I shouldn't do it for you

This is unnecessary, and should be deleted.

cc @SAdams601

I was wondering if it would be possible for ghc-hare to produce a patch or a diff instead of refactored files.

module A where
  f x = let g = g in x

Rename x to g is successful, but shouldn't be as the result is not equivalent:

module A where
  f g = let g = g in g

This tool strips lines such as #!/usr/bin/env runhaskell

cc @expipiplus1

See https://ghc.haskell.org/trac/ghc/ticket/10942

Provide a workaround

If we export a type, and import it qualified, the "rename" refactoring will not rename it.

Github in mobile verson shows only three first paragraphs of README.md:

The text "Home is now https://github.com/RefactoringTools/HaRe" could easily go a bit more down making room for 'Project Liveness' indicators such a the badges.

It is great that the project statement fits in there already.

Possibly based on https://github.com/alanz/HaRe/tree/master/old/editors/Vim

cc @gibiansky

Originally https://github.com/alanz/HaRe/issues/40

I can't install Hare for lts 11.5 - I assume it is not supported, or am I doing something wrong?

I think it might be nice for HaRe to be able to inline and remove a given type synonym. It's not particularly common, but its a trivial refactor that is automatable.

Not sure how involved this would be given quantified types and whatnot, but it seems like a nice-to-have

From reddit

"I'd imagine the IDE tooling would be seriously impressive. Some features off the top of my head:

• Quick abstraction. You highlight a bit of code, press a hotkey, type in a function name and it splits out into its own function.

• An inliner. Similar to the above, it could replace a call to a function with an inlined version if you wanted to get rid of some abstraction with the option to inline it via a lambda.

• Some 'quality of life' things like converting between let and where wish the push of a hotkey.

• Automatic converter to pointfree similar to http://pointfree.io

• Autocomplete that takes types into account.

• Function search of libraries integrated via hoogle.

• type 'coercer' such as you type in a function and it needs a text, but you gave it a string, it could add the corresponding conversion function.

• Convert between sugared and non sugared code, such as do syntax."
  `

When a test suite or executable lists the library in a cabal file as a dependency, process a consolidated module graph for it, as if each module of the library was explicitly listed in the other-modules section

This may require changes to ghc-mod

There is a long-standing issue in VS Code that causes diagnostic reports (such as via haskell-lsp) to be treated as if they apply to a different file on case-insensitive file systems, if Code was opened in a non-canonically-cased path.

For example:

cd c:\users\myself\projects\my-project
code .

According to the HIE log, haskell-lsp was initialized in the directory

c:\users\myself\documents\projects\my-project

and HaRe is sending back messages for the URI

file:///C%3A/Users/myself/Documents/Projects/my-project/Thingy.hs.

The associated diagnostics (squiggles etc.) do not appear in the expected editor window; instead, VS Code reports a problem in what appears to be a distinct file, at the canonicalized path, which by this point is out of sync with my original file (since it lacks changes that had not yet been saved to disk).

There are a couple of workarounds for this:

• Only open Code using the context menu in Explorer, so that it isn't loaded in a non-canonically-cased directory
• Use tab completion in PowerShell (or whatever) when running code on the command line, which automatically corrects casing

This still leaves the issue as a gotcha if the user happens to overlook an incorrectly-cased directory at the command prompt. Given that the VS Code issue has been open for a year and a half, with several apparently unsuccessful attempts at resolving it, I wonder if it would be easier to fix it here by avoiding changing the casing on the path after refactoring.

Unfortunately I don't know enough about how HaRe works to know if that would break other stuff. Does anyone know if it is sufficient to call System.Directory.makeAbsolute, or is the canonicalization necessary for other reasons so we cannot address it here?

Relevant commits include

• 3cdf330 - ghc-mod no longer changes to the cradle dir.
• 084e89b - Canonicalize file paths so command line file paths match loaded module graph

Originally https://github.com/alanz/HaRe/issues/12

For the code at https://github.com/alanz/tide/blob/f1048311dd9ddda115ef06c57825720d046af12d/src/Lex.hs#L135

• using liftOneLevel introduces a syntactically invalid where clause as it is located at the wrong place
• lifting to the top level does not add a parameter for the locally bound variable item.

Originally https://github.com/alanz/HaRe/issues/17 by @ddssff

I don't know if this sounds interesting, but it would be useful to me to have emacs integration of the import cleaning facility in the module-management package. The package is also working towards being able to move declarations between modules.

With

f = bottomFunc 1
  where bottomFunc n = n +1 -- cursor is on the beginning of "buttomFunc"

I run hare-refactor-lift-one and the result in *Messages* reads:

Running...done
Res=[1 of 5]

There is no change of code in my buffer or project directory. The same happens when I try to run hare-refactor-rename, etc. What does this mean? How do I fix it?

Trying to rename something in a file with

{-# ANN module ("HLint: ignore Eta reduce"         :: String) #-}

results in

<- {"fail":{"msg":"rename: \"hsVisibleDsRdr nm:no match for:
(L {src/Language/Haskell/LSP/Core.hs:50:1-65} 
 (HsAnnotation \"{-# ANN\" 
  (ModuleAnnProvenance) 
  (L {src/Language/Haskell/LSP/Core.hs:50:16-61} 
   (HsPar 
    (L {src/Language/Haskell/LSP/Core.hs:50:17-60} 
     (ExprWithTySig 
      (L {src/Language/Haskell/LSP/Core.hs:50:17-42} 
       (HsLit 
        (HsString \"\\\"HLint: ignore Eta reduce\\\"\" {FastString: \"HLint: ignore Eta reduce\"}))) 
      (HsIB 
       (PlaceHolder) 
       (HsWC 
        (PlaceHolder) 
        (Nothing) 
        (L {src/Language/Haskell/LSP/Core.hs:50:55-60} 
         (HsAppsTy 
          [
           (L {src/Language/Haskell/LSP/Core.hs:50:55-60} 
            (HsAppPrefix 
             (L {src/Language/Haskell/LSP/Core.hs:50:55-60} 
              (HsTyVar 
               (L {src/Language/Haskell/LSP/Core.hs:50:55-60} 
                (Unqual {OccName: String}))))))]))))))))))\"","code":"PluginError","info":null}}

there's a stack file for the newer compiler version, but the readme says it only works for 7.0.2.

Hi, I am trying to get HaRe Version 0.8.4.0 x86_64 to run with ghc 8.0.2 on MacOs 10.12.3

The wiki says "(add-to-load-path "~/.cabal/share/x86_64-linux-ghc-7.10.2/HaRe-0.8.2.0/elisp")".
On mac, that's obviously wrong. However I did not find any other place where the HaRe elisp got installed. Please advise and provide documentation.

Regards, Andy

Originally https://github.com/alanz/HaRe/issues/28

This is only really practical once the elisp is on MELPA, I suspect.

Unless the haskell-mode integration does this automatically

Renaming fails when trying to change LL to L in the following snippet

import Data.List as LL

foo = 'a' LL.: ['b']

Was https://github.com/alanz/HaRe/issues/39

Once an ediff session is complete for a preview of changes, close the proposed change buffer.

The problem is to integrate HaRe with existing build system which relies on --package-db to provide package locations.

By definition HaRe can only change code that already compiles.

If a refactoring is attempted and the compilation fails while loading a module, report this appropriately, so an IDE can report it as an underlying source error rather than an error in the refactoring being attempted, or in HaRe

The code for both the library and the executable is in the same directory. When compiling the executable, GHC does not look in the HaRe library it just built, but instead thinks that the code in src/ is part of the executable and compiles it again from scratch.

The compilation time of the package can be halved by moving the library or the executable in separate directories.

When trying any refactoring from the "Refactorer" menu I get nothing but errors.

From the Messages buffer:

Res=RefSet
equal: Wrong type argument: sequencep, RefSet
Running...done
Res=cabal-helper-wrapper:
equal: Wrong type argument: sequencep, cabal-helper-wrapper:

I use stack lts-4.0 with a recent ghc emacs plugin.

I installed hare and ghc-mod via stack.