[Haskell-cafe] GSoC proposal: Haskell AST-based refactoring and API upgrading tool

[Roman Cheplyaka]

* Niklas Hambüchen <mail at nh2.me> [2013-04-29 14:00:23+0800]
> I would like to propose the development of source code refactoring tool
> that operates on Haskell source code ASTs and lets you formulate rewrite
> rules written in Haskell.

Hi Niklas,

This is a great idea. I talked about it at HIW last year[1] and have
been working on it since then.

[1]: http://www.youtube.com/watch?v=Ae-6uIMQPmU

1. What you call a "full-source" AST is already present in
   haskell-src-exts (under "Annotated" subtree). It /almost/ satisfies

     pretty .  parse = id,

   (one thing it fails to do is to preserve tabs), and fixing it should
   be definitely easier than starting from scratch.

2. HSE has two pretty-printers: an exact one, and one that ignores
   annotations and pretty-prints in its own style. It's important to
   have a mixture of both, so that we can pretty-print generated
   snippets and splice them into an already formatted AST. A friend of
   mine, Pavel Poukh, is working on a pretty-printer that produces an
   annotated tree instead of a flat string, and AFAIK that work is close
   to done.

   [2]: https://github.com/Pnom/haskell-ast-pretty

3. A major thing that I devoted my time to is name resolution and
   package management [3,4], which are necessary for the tool to work.

   [3]: https://github.com/feuerbach/haskell-names
   [4]: https://github.com/feuerbach/haskell-packages

   They are also close to done.

4. As for the tool itself, I have a crude prototype [5], but I
   haven't updated it for a while.

   [5]: https://github.com/feuerbach/hasfix

5. The user interface is, of course, an important topic by itself. I
   was thinking of something less expressive and more declarative, but
   your idea is also interesting. Let's discuss this separately.

Regarding this topic as a GSoC project, I'm not so sure this is a good
idea. As a past GSoC student myself, I feel that new projects (as
opposed to established projects with existing user base and development
team) have much greater risks. (This is also backed up by data [6].)

But if you (or anyone else who happens to read this) would like to get
involved, please get in touch with me!

[6]: http://www.gwern.net/Haskell Summer of Code

Roman