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:-( http://www.cs.kent.ac.uk/people/rpg/cr24/medina/ 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 http://www.cs.kent.ac.uk/people/staff/cr3/toolbox/haskell/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 area.
- 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 http://www.cs.kent.ac.uk/people/rpg/cr24/medina/examples.shtml (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. Cheers, Claus