ANNOUNCE: HaRe, the Haskell Refactorer, version 0.1
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.1 (also known as HaRe 01/10/2003 ;-), a snapshot of our Haskell Refactorer prototype. You can get it 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: our project address at kent.ac.uk is refactor-fp (which we'd like to keep spam-free). An initial catalogue describing the refactorings implemented in HaRe (with slightly different names) is included in the doc/ directory. Happy Refactoring! The HaRe Team (Huiqing Li, Claus Reinke, Simon Thompson) ---------------------------------------------------------------------- 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 and the papers/presentations/catalogue/demo/etc. available there, especially our contribution to this year's Haskell Workshop. HaRe - the Haskell Refactorer: HaRe is our prototype tool supporting a first few basic 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-5.04.3) and run on most flavours of Windows (cygwin needed to build) and on Suns (binutils recommended to build), 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 A series of screenshots illustrating some of the tasks one might want to accomplish with these refactorings can be found via the HaRe page (see above for URL). 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 indispensible for Haskell development, and while we won't be able to follow every suggestion, we've got almost two more years in which to work towards this goal!-) History: Functionally, this is still roughly the snapshot you've seen at the Haskell workshop, packaged up for relative ease of build/use. Indeed, interim snapshots have been available all through September, 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.
On Thu, Oct 02, 2003 at 11:19:47AM +0100, C.Reinke wrote:
we are pleased to announce the availability of HaRe 0.1 (also known as HaRe 01/10/2003 ;-), a snapshot of our Haskell Refactorer prototype.
Thank you - looks pretty nice! Any chance of XEmacs support too? :-) Jens
we are pleased to announce the availability of HaRe 0.1 (also known as HaRe 01/10/2003 ;-), a snapshot of our Haskell Refactorer Thank you - looks pretty nice! thanks! Any chance of XEmacs support too? :-)
Ah, there we go;-) Two answers: 1. what little I know about Emacs scripting I learned during this project, so I wouldn't even know what is different in XEmacs or why XEmacs doesn't work with the Emacs version of the interface. Help from X/Emacs hackers is welcome. 2. we don't want to get bogged down in supporting various frontends, but we do want to enable others to contribute interface versions for their favourite editor/IDE. According to a survey we did here a while ago, Vim and Emacs cover the majority of Haskell programmers' environments (we didn't distinguish between the various members of the families). However, the main reason that we try to support two editor interfaces is to avoid dependencies on features only available in one specific editor. In other words, if we can script interfaces for both Vim and Emacs, and you are not using these popular editors, you can probably script an interface to HaRe for your own editor (unless that editor is overly limited;-). If you need help with the HaRe-side of the interface, just let us know (kent.ac.uk, project mailing list: refactor-fp). Was that what you wanted to hear?-) Claus
"CR" == Claus Reinke <claus.reinke@talk21.com> writes:
>> Any chance of XEmacs support too? :-) CR> 1. what little I know about Emacs scripting I CR> learned during this CR> project, so I wouldn't even know what is CR> different in XEmacs or why XEmacs doesn't work CR> with the Emacs version of the interface. Help CR> from X/Emacs hackers is welcome. Well the little time I have for hacking I prefer to give to Haskell, but perhaps after playing with HaRe under Emacs I can try to make it work with XEmacs if I find some time. :-) CR> 2. we don't want to get bogged down in supporting CR> various CR> frontends, but we do want to enable others to CR> contribute interface versions for their CR> favourite editor/IDE. So I understand patches are accepted. :-) Cheers, Jens
participants (3)
-
C.Reinke -
Claus Reinke -
Jens Petersen