[Haskell-cafe] Target Selection in HaRe

AlanKim Zimmerman alan.zimm at gmail.com
Tue Jan 14 10:31:26 UTC 2014

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

On Jan 14, 2014 6:25 PM, "JP Moresmau" <jpmoresmau at gmail.com> 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 <alan.zimm at gmail.com>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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> --
> JP Moresmau
> http://jpmoresmau.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140114/527900e0/attachment.html>

More information about the Haskell-Cafe mailing list