ANNOUNCE: HaRe, the Haskell Refactorer, version 0.1

C.Reinke C.Reinke at
Thu Oct 2 15:38:18 EDT 2003

> First, let me say that I'm intrigued.  This looks like really neat
> functionality to have available.

Thanks; obviously, we think so, too!

> I'm curious whether you are planning (or have developed) tools to
> *detect* cases for refactoring?  Occasionally, I find myself wishing
> for a tool to help me clean up a finished program, by e.g.

There are well-established connections between refactoring and
software metrics (or smell detection, as the oo folks like to call
it;-), and there are whole groups of tools/software engineering
ideas that need porting and adaption to Haskell (change impact
analysis/visualisation anyone?).  

Chris Ryder here has been working on a metrics and visualisation
library for Haskell (but according to his own metrics, he claims
it's not ready for release yet:-(

and although he's been moving to visualisation and other work
recently, we're interested in any suggestions of what you'd like to
see (no promises that we'll implement such..). We'd certainly like
to use Chris' Medina experience, and perhaps part of the library
itself, to build actual tools on top of them, but may not have the
resources to do this ourselves. If anyone else is working on this,
please let us know - we'd like to collaborate towards an integration
of such tools with HaRe.

> - removing unused items from export/import lists

Some of you might recall my using Hugs for creating export/import
lists from within Vim

That is functionality we'd like to integrate into HaRe, as soon as
we've made it module-aware. It depends a bit on what you mean by
"unused" in connection with modules/libraries (refactoring gets even
trickier when you do not have access to all clients of your module),
but there are certainly some things we can and want to do in this

> - identifying functions which are only used in one place (and thus
>   candidate for inclusion in 'where' clauses)

Again, implicit export lists are likely to interfere (if everything
is exported by default, you don't know whether its going to be
used), such functions often occur in intermediate stages of program
redesign: you move them to the top level so that you may then start
using them elsewhere, and such functions (or even unused ones) occur
in libraries, where you don't want to hide/remove them. 

A general problem/feature of refactorings is that there is no normal
form for program designs, and no unique orientation for refactoring
transformations: depending on the situation, you might want to apply
them in either direction, so if you'd just tried to highlight places 
in your code to which refactorings are applicable, you might end up
highlighting most of your code..

With those caveats, a general scheme might need some more thinking,
but perhaps it makes sense to be able to choose a particular
refactoring/orientation and look for places it might be applied to.

> - identifying functions defined in one module, but only (mainly?) used
>   by/depending on functions in another module, and thus candidate for
>   cross-module migration.

All the caveats for modules/libraries apply here, but this is a
prime example of what one would want to use a metrics/visualisation
tool for: visualise the dependencies between modules and the
entities they define/use to get an impression of whether the current
modularisation could be improved.

Have a look at the module browser example at

(you'll need an SVG plugin, and experiment with its controls),
perhaps you can help to encourage Chris to release things like that?

> - perhaps similarly, identify function transformation that reduces
>   the parameter lists (i.e. exposed function interface)

Yes, the old correspondence principle for language design (between
definitions and parameters) applies to refactorings as well: most
refactorings for definitions have a sensible equivalent for
parameters, and vice versa.

> and so on.  (Does that make sense at all? :-)

not at all!-) Thanks for the suggestions, we'll try to keep them 
in mind, although I hope you can see that some of them are not
straightforward to pin down.


More information about the Haskell-Cafe mailing list