<div dir="ltr">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. <div><br></div><div>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.<div><br></div><div>Also, I <i>very strongly</i> 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.</div><div><br></div><div>(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.)</div><div><br></div><div>-- Andrew</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 11:34 AM, Alan & Kim Zimmerman <span dir="ltr"><<a href="mailto:alan.zimm@gmail.com" target="_blank">alan.zimm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>There are a number of changes in GHC 7.10 that will make it easier for<br>tool writers to use the GHC API.<br><br>These include<br><br>1. More parser entrypoints, to explicitly parse fragments [Andrew Gibiansky]<br><br> The following parsers are now provided<br><br>   parseModule, parseImport, parseStatement, ​ parseDeclaration,<br>   parseExpression, parseTypeSignature, ​ parseFullStmt, parseStmt,<br>   parseIdentifier, ​ parseType, parseHeader<br><br>2. No more landmines in the AST [Alan Zimmerman]<br><br> In the past it was difficult to work with the GHC AST as any generic<br> traversals had to carefully tiptoe around an assortment of panic and<br> undefined expressions. These have now been removed, allowing<br> standard traversal libraries to be used.<br><br>There is a third change currently being discussed, and I would like<br>feedback on it's desirability.<br><br>3. Introduce an annotation structure to the ParsedSource to record the<br>location of uncaptured keywords.<br><br> At the moment the location of let / in / if / then / else / do<br> etc is not captured in the AST. This makes it difficult to<br> parse some source, transform the AST, and then output it again<br> preserving the original layout.<br><br> The current proposal, which can be seen at [1] and a proof of<br> concept implementation at [2] returns a structure keyed to each AST<br> element containing simply the specific SrcSpan's not already<br> captured in the AST.<br><br> This is the analogue of the Language.Haskell.Exts.Annotated.Syntax<br> from haskell-src-exts, except a custom SrcSpanInfo structure is<br> provided for each AST element constructor, and it is not embedded<br> within the AST.<br><br> [1] <a href="https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations</a><br> [2] <a href="https://phabricator.haskell.org/D297" target="_blank">https://phabricator.haskell.org/D297</a><br><br>So, apart from HaRe, are there any other users who would be interested<br>in using this?<br><br></div>Regards<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"> Alan<br><div><div><br><br></div></div></font></span></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>