GHC AST Annotations
Alan & Kim Zimmerman
alan.zimm at gmail.com
Thu Aug 28 19:32:18 UTC 2014
I have started capturing the discussion here
On Thu, Aug 28, 2014 at 8:34 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
> This does have the advantage of being explicit. I modelled the initial
> proposal on HSE as a proven solution, and I think that they were trying to
> keep it non-invasive, to allow both an annotated and non-annoted AST.
> I thiink the key question is whether it is acceptable to sprinkle this
> kind of information throughout the AST. For someone interested in
> source-to-source conversions (like me) this is great, others may find it
> The other question, which is probably orthogonal to this, is whether we
> want the annotation to be a parameter to the AST, which allows it to be
> overridden by various tools for various purposes, or fixed as in Richard's
> A parameterised annotation allows the annotations to be manipulated via
> something like for HSE:
> -- |AST nodes are annotated, and this class allows manipulation of the
> class Functor ast => Annotated ast where
> -- |Retrieve the annotation of an AST node.
> ann :: ast l -> l
> -- |Change the annotation of an AST node. Note that only the annotation
> of the node itself is affected, and not
> -- the annotations of any child nodes. if all nodes in the AST tree are
> to be affected, use fmap.
> amap :: (l -> l) -> ast l -> ast l
> On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg <eir at cis.upenn.edu>
>> For what it's worth, my thought is not to use SrcSpanInfo (which, to me,
>> is the wrong way to slice the abstraction) but instead to add SrcSpan
>> fields to the relevant nodes. For example:
>> | HsDo SrcSpan -- of the word "do"
>> (HsStmtContext Name) -- The parameterisation is
>> -- because in this context we never
>> -- the PatGuard or ParStmt variant
>> [ExprLStmt id] -- "do":one or more stmts
>> PostTcType -- Type of the whole expression
>> data BlockSrcSpans = LayoutBlock Int -- the parameter is the indentation
>> ... -- stuff to track the appearance of
>> any semicolons
>> | BracesBlock ... -- stuff to track the braces and
>> The way I understand it, the SrcSpanInfo proposal means that we would
>> have lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I
>> Popping up a level, I do support the idea of including this info in the
>> On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones <simonpj at microsoft.com>
>> > In general I’m fine with this direction of travel. Some specifics:
>> > · You’d have to be careful to document, for every data
>> constructor in HsSyn, what the association between the [SrcSpan] in the
>> SrcSpanInfo and the “sub-entities”
>> > · Many of the sub-entities will have their own SrcSpanInfo
>> wrapped around them, so there’s some unhelpful duplication. Maybe you only
>> want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities (like the
>> syntactic keywords) that do not show up as children in the syntax tree?
>> > Anyway do by all means create a GHC Trac wiki page to describe your
>> proposed design, concretely.
>> > Simon
>> > From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Alan
>> & Kim Zimmerman
>> > Sent: 28 August 2014 15:00
>> > To: ghc-devs at haskell.org
>> > Subject: GHC AST Annotations
>> > Now that the landmines have hopefully been cleared from the AST via 
>> I would like to propose changing the location information in the AST.
>> > Right now the locations of syntactic markers such as do/let/where/in/of
>> in the source are discarded from the AST, although they are retained in the
>> rich token stream.
>> > The haskell-src-exts package deals with this by means of using the
>> SrcSpanInfo data type  which contains the SrcSpan as per the current GHC
>> Located type but also has a list of SrcSpan s for the syntactic markers,
>> depending on the particular AST fragment being annotated.
>> > In addition, the annotation type is provided as a parameter to the AST,
>> so that it can be changed as required, see .
>> > The motivation for this change is then
>> > 1. Simplify the roundtripping and modification of source by explicitly
>> capturing the missing location information for the syntactic markers.
>> > 2. Allow the annotation to be a parameter so that it can be replaced
>> with a different one in tools, for example HaRe would include the tokens
>> for the AST fragment leaves.
>> > 3. Aim for some level compatibility with haskell-src-exts so that tools
>> developed for it could be easily ported to GHC, for example exactprint .
>> > I would like feedback as to whether this would be acceptable, or if the
>> same goals should be achieved a different way.
>> > Regards
>> > Alan
>> >  https://phabricator.haskell.org/D157
>> > 
>> > 
>> > 
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs