I am very much in favor of this. IHaskell does not need this (...yet?), but I have played around with writing other source-transforming tools, and having to rely on HSE for parsing and reformatting and relying on GHC API for interpreting and typechecking is a little bit of a pain. 

Besides HaRe, I'd love a tool equivalent to `go fmt` which normalized stuff like indentation, alignment, and usage of `where` vs `let`, and automatically applied various changes (of course details are complicated); that sort of thing requires good support for the sort of work you're doing in HaRe.

Also, I very strongly support any work that goes into improving the GHC API. Working with it was a nightmare at the beginning due to lack of documentation, lack of exposed symbols, and other issues.

(That said, I'm also fine with using the dynamic typing approach that was mentioned elsewhere to avoid an extra type parameter. Have the annotation be a Dynamic or something. The motivation for this would be to make the change less intrusive.)

-- Andrew

On Wed, Oct 1, 2014 at 11:34 AM, Alan & Kim Zimmerman <alan.zimm@gmail.com> wrote:
There are a number of changes in GHC 7.10 that will make it easier for
tool writers to use the GHC API.

These include

1. More parser entrypoints, to explicitly parse fragments [Andrew Gibiansky]

  The following parsers are now provided

    parseModule, parseImport, parseStatement, ​ parseDeclaration,
    parseExpression, parseTypeSignature, ​ parseFullStmt, parseStmt,
    parseIdentifier, ​ parseType, parseHeader

2. No more landmines in the AST [Alan Zimmerman]

  In the past it was difficult to work with the GHC AST as any generic
  traversals had to carefully tiptoe around an assortment of panic and
  undefined expressions. These have now been removed, allowing
  standard traversal libraries to be used.

There is a third change currently being discussed, and I would like
feedback on it's desirability.

3. Introduce an annotation structure to the ParsedSource to record the
location of uncaptured keywords.

  At the moment the location of let / in / if / then / else / do
  etc is not captured in the AST. This makes it difficult to
  parse some source, transform the AST, and then output it again
  preserving the original layout.

  The current proposal, which can be seen at [1] and a proof of
  concept implementation at [2] returns a structure keyed to each AST
  element containing simply the specific SrcSpan's not already
  captured in the AST.

  This is the analogue of the Language.Haskell.Exts.Annotated.Syntax
  from haskell-src-exts, except a custom SrcSpanInfo structure is
  provided for each AST element constructor, and it is not embedded
  within the AST.

  [1] https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
  [2] https://phabricator.haskell.org/D297

So, apart from HaRe, are there any other users who would be interested
in using this?

Regards
  Alan



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe