Dear Haskellers, As part of our project on Refactoring Functional Programs http://www.cs.kent.ac.uk/projects/refactor-fp/ we are pleased to announce the availability of HaRe 0.3 (also known as HaRe 19/11/2004), a snapshot of our Haskell Refactorer prototype. Apart from bug-fixes, there are two major changes since HaRe 0.2. First, a number of new refactorings have been added to HaRe. They are of two kinds: module refactorings such as cleaning the imports, moving a definition from one module to anther module, etc. and data-oriented refactorings such as from concrete to abstract data type. Second, we have evolved the architecture of HaRe and derived an API (documented using Haddock) for program analysis and transformation. This allows HaRe to serve as a framework for end-users to build their own refactorings or just program transformations. You can get HaRe 0.3 and the documentation about how to build your own refactorings via: http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Please see the README.txt for build/use instructions and known issues, and let us know about any problems, bugs, suggestions or additional platforms you can confirm as working. Happy Refactoring! The HaRe Team (Huiqing Li, Chris Brown, Claus Reinke, Simon Thompson) Project email: refactor-fp@kent.ac.uk Background: Refactoring is the process of changing the structure of programs without changing their functionality, i.e., refactorings are meaning-preserving program transformations that implement design changes. For more details about refactoring, about our project and for background on HaRe, see our project pages. HaRe - the Haskell Refactorer: HaRe is our prototype tool supporting a collection of refactorings for Haskell 98 (see README.txt for known issues and limitations). It is implemented as a separate refactoring engine (on top of Programatica's Haskell frontend and Strafunski's generic traversal strategy library), with small scripting frontends that call this engine from either Vim or Emacs. The refactoring engine itself has been seen to build (with ghc-6.2.1) and run on most flavours of Windows (cygwin needed to build) and on Suns, so we expect it to build and work on other unix-like platforms with almost no changes. In other words, we've tried to make sure that most of you should be able to build and use HaRe from your favourite OS/editor. Currently supported refactorings: removeDef : remove an unused definition duplicateDef : duplicate a definition under a new name liftToTopLevel : move a local definition to top level liftOneLevel : move a local definition one level up demote : move a definition local to point of use rename : rename an identifier introNewDef : turn expression into use of new definition unfoldDef : replace use of identifier by right-hand side addOneParameter: add parameter to definition rmOneParameter : remove unused parameter from definition generaliseDef : turn expression on rhs of definition into new parameter of that definition clean imports : clean the imports to remove unnecessary ones make import explicit: make the used entities explicit in the identified import declaration add to export : add an item to the export list remove from export : remove an item from the export list move def to another module : move a definition from one module to another module From concrete to abstract data type: transform a concrete data type to an abstract one, which is composed from a sequence of elementary refactorings. Caveats (see also README.txt): Please keep in mind that this is a prototype, so we do not recommend to use it on your productions sources just yet. Just play with it to get an idea of tool-supported refactoring in Haskell, and send us your feedback and bug-reports. Our goal is to develop this into a tool that many of you will find indispensable for Haskell development. History: Functionally, HaRe 0.1 was still roughly the snapshot you'd seen at the Haskell workshop, packaged up for relative ease of build/use, but unaware of types and modules, and all refactorings only working on a single module. It had some annoying issues that plagued some of our Emacs users, didn't work at all with literate Haskell files, and had several other minor problems. HaRe 0.2 did not add refactorings, but all refactorings were modified to take Haskell's module system into account. This means that a single refactoring may affect multiple modules in a given project (e.g., renaming an exported function should trigger corresponding renamings in all client modules that are part of the current project), that export/import lists have to be respected or adapted, and that generally the refactorings should now work in multi-module settings. Beyond these major changes, several issues in the Emacs version of the user interface have been ironed out, there is initial support for literate Haskell files, and lots of smaller issues have been dealt with (see README.txt for a few more details). Interim snapshots have been available since December last year, and some of you have already played with those. The earliest snapshots were somewhat buggy, but over the last weeks the software has stabilised to the extent that we are back to Bug 0 (aka: insufficient test-coverage!-), and the time has come to distribute the current snapshot more widely.