Difference between revisions of "HaRe"

From HaskellWiki
Jump to navigation Jump to search
m (fixing github url)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
= The HaRe Project =
 
= The HaRe Project =
   
  +
This page is a little stale the latest version, from the [https://github.com/alanz/HaRe github], of HaRe is working with the GHC api and the latest update seem to be on the [https://plus.google.com/communities/116266567145785623821 google+ community page.] [[User:Davorak|Davorak]] 18:58, 29 April 2013 (UTC)
Currently, HaRe is a full Haskell 98 refactoring tool for automated refactoring of Haskell 98 programs. It is integrated with Emacs and Vim. Future plans are to extend support for Haskell 2010 and other language extensions.
 
   
 
Currently, HaRe is a Haskell 98/2010 refactoring tool for automated refactoring of Haskell programs. It is integrated with Emacs.
The project is lead by [http://www.cs.st-andrews.ac.uk/~chrisb/ Chris Brown].
 
   
  +
It is being rewritten to use the GHC API.
* [http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Project homepage]
 
  +
 
The project was previously lead by [http://www.cs.st-andrews.ac.uk/~chrisb/ Chris Brown], it is currently being developed by [http://www.github.com/alanz Alan Zimmerman]
  +
  +
* [https://github.com/alanz/HaRe/ HaRe development on github]
 
* [http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html Overall Project homepage] (a bit stale)
 
* [http://hackage.haskell.org/package/HaRe Stable release] (on hackage)
 
* [http://hackage.haskell.org/package/HaRe Stable release] (on hackage)
  +
* [http://www.cs.kent.ac.uk/projects/refactor-fp/hare/demo.html Screenshots]
  +
* [https://github.com/RefactoringTools/HaRe/wiki HaRe Wiki]
   
 
== Roadmap (sketch) ==
 
== Roadmap (sketch) ==
  +
* Complete port to GHC API, and extend supported refactorings
 
* API decisions (ghc-api/ programmatica/ haskell-src-exts)
 
* API decisions (ghc-api/ programmatica/ haskell-src-exts)
 
* Extending refactorings to cope with new extensions
 
* Extending refactorings to cope with new extensions
Line 15: Line 23:
 
* Better examples, user extension documentation
 
* Better examples, user extension documentation
 
* Maintainance and portability long term.
 
* Maintainance and portability long term.
  +
  +
  +
This next section needs to be updated
  +
  +
== Infrastructure ==
  +
* HaRe is currently built upon the Programatica project for access to an AST and Token Stream and Strafunski for generic tree traversal.
  +
* HaRe uses the Programatica front-end to parse full Haskell projects into an AST with static semantics, and a token stream. Programatica's token stream contains layout and comments together with position information, which HaRe uses (in combination with the AST) to pretty-print the refactored programs. HaRe attempts to produce refactored output that looks as close as possible to the original program.
  +
* Strafunski is used for tree traversal and transformation. In particular, Strafunski has a powerful and expressible mode of traversal, allowing all nodes, some nodes or one node to be traversed/transformed.
  +
* Static semantics are vital for refactorings that require binding information of variables. Renaming, for instance, renames all occurrences of a name within its scope. This scope information is currently retrieved from the AST. In addition to this, static semantics are also vital for HaRe to identify particular expressions for refactoring and to also pretty-print the refactored output (together with the token stream).
  +
* The refactorings in HaRe are relativity low level, working directly on the AST for transformation. An underlying [http://www.cs.kent.ac.uk/projects/refactor-fp/hare/haddock/0.5/API/RefacUtils.html API] is used to build the transformations and queries.
  +
* Some refactorings require types, which are retrieved using hint.
  +
* HaRe is integrated into Emacs and VIm: when a new refactoring is added, the build system generates the Emacs and VIm scripts automatically.
  +
  +
== Some Problems to Address ==
  +
* Programatica is only Haskell 98. HaRe currently will not parse a Haskell program that is not 98.
  +
* Programatica is no longer maintained: we need a parser that is maintained and up-to-date with the current language standard and extensions.
  +
* Scrap-your-boilerplate may be more suitable these days for generics.
  +
* We require static semantics. Packages such as haskell-src-exts do not provide this. We also require layout and comments to be preserved.
  +
* Type information in the AST would be useful.
  +
* Moving to Scion for editor interfacing. This would eliminate the dependency for Emacs and Vim, and make HaRe more usable to people using other systems.
  +
* HaRe currently uses a two-tier state monad. The first layer being Programatica's parser monad, and then HaRe's own state monad underneath. The reason for this is to plumb the token stream (and AST) through the program implicitly. Transformations can then be performed using (typically) an update function. It may be wise to simplify this design.
  +
* The implementation of refactorings require reasonable technical knowledge and a steep learning curve. Abstracting away from the internals of HaRe and moving towards a DSL for refactoring would benefit knew refactorings.

Latest revision as of 12:53, 4 August 2014

The HaRe Project

This page is a little stale the latest version, from the github, of HaRe is working with the GHC api and the latest update seem to be on the google+ community page. Davorak 18:58, 29 April 2013 (UTC)

Currently, HaRe is a Haskell 98/2010 refactoring tool for automated refactoring of Haskell programs. It is integrated with Emacs.

It is being rewritten to use the GHC API.

The project was previously lead by Chris Brown, it is currently being developed by Alan Zimmerman

Roadmap (sketch)

  • Complete port to GHC API, and extend supported refactorings
  • API decisions (ghc-api/ programmatica/ haskell-src-exts)
  • Extending refactorings to cope with new extensions
  • Simpler generics for tree traversals.
  • Query / transform language support
  • Better examples, user extension documentation
  • Maintainance and portability long term.


This next section needs to be updated

Infrastructure

  • HaRe is currently built upon the Programatica project for access to an AST and Token Stream and Strafunski for generic tree traversal.
  • HaRe uses the Programatica front-end to parse full Haskell projects into an AST with static semantics, and a token stream. Programatica's token stream contains layout and comments together with position information, which HaRe uses (in combination with the AST) to pretty-print the refactored programs. HaRe attempts to produce refactored output that looks as close as possible to the original program.
  • Strafunski is used for tree traversal and transformation. In particular, Strafunski has a powerful and expressible mode of traversal, allowing all nodes, some nodes or one node to be traversed/transformed.
  • Static semantics are vital for refactorings that require binding information of variables. Renaming, for instance, renames all occurrences of a name within its scope. This scope information is currently retrieved from the AST. In addition to this, static semantics are also vital for HaRe to identify particular expressions for refactoring and to also pretty-print the refactored output (together with the token stream).
  • The refactorings in HaRe are relativity low level, working directly on the AST for transformation. An underlying API is used to build the transformations and queries.
  • Some refactorings require types, which are retrieved using hint.
  • HaRe is integrated into Emacs and VIm: when a new refactoring is added, the build system generates the Emacs and VIm scripts automatically.

Some Problems to Address

  • Programatica is only Haskell 98. HaRe currently will not parse a Haskell program that is not 98.
  • Programatica is no longer maintained: we need a parser that is maintained and up-to-date with the current language standard and extensions.
  • Scrap-your-boilerplate may be more suitable these days for generics.
  • We require static semantics. Packages such as haskell-src-exts do not provide this. We also require layout and comments to be preserved.
  • Type information in the AST would be useful.
  • Moving to Scion for editor interfacing. This would eliminate the dependency for Emacs and Vim, and make HaRe more usable to people using other systems.
  • HaRe currently uses a two-tier state monad. The first layer being Programatica's parser monad, and then HaRe's own state monad underneath. The reason for this is to plumb the token stream (and AST) through the program implicitly. Transformations can then be performed using (typically) an update function. It may be wise to simplify this design.
  • The implementation of refactorings require reasonable technical knowledge and a steep learning curve. Abstracting away from the internals of HaRe and moving towards a DSL for refactoring would benefit knew refactorings.