[Haskell-cafe] Target Selection in HaRe

AlanKim Zimmerman alan.zimm at gmail.com
Mon Jan 27 20:09:34 UTC 2014

Some feedback

HaRe now loads each of the targets in the cabal file in turn, and
stores the module graph for each. When the clients of a module are
requested for a refactoring it takes the union of all modules in the
reachability graph, making sure to treat each Main module as distinct.

So renaming a function in a library will rename it in the executables,
tests, and benchmarks too.


On Tue, Jan 14, 2014 at 12:43 PM, JP Moresmau <jpmoresmau at gmail.com> wrote:

> OK, but I don't really understand how you can do a rename with only "some"
> of the targets. You mean that if I rename a function used in the main
> module of two executables in one single project, the rename will only be
> effective in one executable, and the other one will stop compiling? That
> sounds sub-optimal to me. A lot of project now have several targets;
> executables, test-suites, benchmarks...
> JP
> On Tue, Jan 14, 2014 at 11:31 AM, AlanKim Zimmerman <alan.zimm at gmail.com>wrote:
>> 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" <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/
> --
> JP Moresmau
> http://jpmoresmau.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140127/b0a819b9/attachment.html>

More information about the Haskell-Cafe mailing list