GHC AST Annotations
Alan & Kim Zimmerman
alan.zimm at gmail.com
Thu Aug 28 18:34:34 UTC 2014
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 unimportant
> -- 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 think.
> 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