Ok, that makes sense.
Thanks
Alan
On Wed, Dec 3, 2014 at 1:30 PM, Simon Peyton Jones
Please don’t do (1). That would horribly clutter HsPar.
I suggest (2). Actually I suggest you don’t have the Bool at all. Instead, in the desugarer, if you come across a HsScc, discard it unless it is active. We only need the Bool to cache the “am I active” question if there are zillions of places where we need to know. But I bet there is only one, namely the desugarer.
The spirit of the front end is: leave the source code entirely undisturbed until desugaring. Throwing away HsScc and turning them in HsPar is against this spirit
SImon
*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Alan & Kim Zimmerman *Sent:* 02 December 2014 20:19 *To:* ghc-devs@haskell.org *Subject:* API Annotations and HsSCC / HsTickPragma
I am in the process of working the shiny new API annotations through into a practical example in ghc-exactprint [1], but I have hit a snag.
A SCC annotation appears in the source as
{-# SCC "name" #-} <expression>
and if enabled via -prof results in the expression being wrapped in
HsSCC FastString (LHsExpr id)
BUT, if not enabled, it appears as
HsPar (LHsExpr id)
From the parser/annotation point of view, the appropriate annotations are generated, and can be used to distinguish the two cases. The problem is that the annotations only capture the SrcSpan of the thing being annotated, so in the HsPar case the contents of the FastString is lost.
A similar situation exists for HsTickPragma,
HsTickPragma -- A pragma introduced tick (FastString,(Int,Int),(Int,Int)) -- external span for this tick (LHsExpr id)
which also degrades to HsPar
I see a number of possible solutions
1. Add the missing information to HsPar in a Maybe
HsPar (Maybe (FastString,(Int,Int),(Int,Int))) (LHsExpr id)
2. Modify HsSCC / HsTickPragma to have a Bool indicating whether they are active or not.
3. Introduce an additional annotation type to carry the missing information.
I welcome advice on the best way forward.
Alan