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
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.JPOn Tue, Jan 14, 2014 at 11:04 AM, AlanKim Zimmerman <alan.zimm@gmail.com> wrote:
AlanDoes anyone have any preferences in terms of this?4. A different option, or blend of the above.e.g. load the union but specify the specific main module.The problem with this is that it then becomes difficult to refactor a main module.3. Try to build up a union of the module graph for all the targets, excluding all main modules.2. Create a config file that lives in the project directory and specifies the targets to be loadedThis means the IDE integration is going to have to provide a way of deciding the scope of the refactoring.1. require the names of the target(s) to be loaded to be passed in as command line arguments.Options that seem viable areI 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.The problem is that GHC is unable to load more than one main file.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 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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
JP Moresmau
http://jpmoresmau.blogspot.com/