Re: [Haskell-cafe] Target Selection in HaRe

I'm trying to steer away from a database if I can avoid it. And also hoping to not have to store meta information outside the GHC AST to do a multi phase refactor, e.g. the usage information to know where a name was used for renaming. I think the union will work best, with some kind of selection of the current main to work with, or just store the additional info for the main modules. Alan On Jan 14, 2014 6:25 PM, "JP Moresmau" wrote:

Can't you do the union of module graphs for all targets by adding the file names to the modules or something, so you could have several main modules using different files in a general graph? What I know is how we do renames in EclipseFP: we use the GHC API to generate usage information for each different targets then the data is actually stored in a DB, and the Java code uses this info to perform renames everywhere (across projects, even). Of course you don't want all that, but you should be able to decorate the module graph with file names and perform the union.

JP

On Tue, Jan 14, 2014 at 11:04 AM, AlanKim Zimmerman wrote:

...

The Haskell Refactorer now makes use of the GHC API to load and typecheck the code to be refactored.

It uses ghc-mod internally to identify a project cabal file, and extract the targets in it.

The current code attempts to load all the targets into the module graph, to make sure that when a project is refactored the ancillary parts such as tests and benchmarks are refactored too, e.g. when renaming a function.

The problem is that GHC is unable to load more than one main file.

I am trying to decide on the best way of resolving this in terms of a user of HaRe, where it should 'just work' most of the time. The actual refactoring is done by calling the HaRe executable with command line arguments.

Options that seem viable are

1. require the names of the target(s) to be loaded to be passed in as command line arguments.

This means the IDE integration is going to have to provide a way of deciding the scope of the refactoring.

2. Create a config file that lives in the project directory and specifies the targets to be loaded

3. Try to build up a union of the module graph for all the targets, excluding all main modules.

The problem with this is that it then becomes difficult to refactor a main module.

4. A different option, or blend of the above.e.g. load the union but specify the specific main module.

Does anyone have any preferences in terms of this?

Alan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- JP Moresmau http://jpmoresmau.blogspot.com/