API Annotations and HsSCC / HsTickPragma

[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 at haskell.org] On Behalf Of Alan & Kim Zimmerman
Sent: 02 December 2014 20:19
To: ghc-devs at 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


[1] https://github.com/alanz/ghc-exactprint/tree/wip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141203/1e7c7ba4/attachment-0001.html>