Skip to content

EPA : Should there be a Monoid instance for EpAnn payload?

The EpAnn data structure is defined as

data EpAnn ann
  = EpAnn { entry     :: Anchor
           , anns     :: ann
           , comments :: EpAnnComments
           }
  | EpAnnNotUsed

In order to be able to write code that for example adds comments to an arbitrary EpAnn, we require a way to make an empty value for the anns field.

addCommentsToEpAnn loc EpAnnNotUsed cs
  = EpAnn (Anchor (realSrcSpan loc) UnchangedAnchor) mempty cs
addCommentsToEpAnn _ (EpAnn a an ocs) ncs = EpAnn a an (ocs <> ncs)

To date we have been requiring Monoid for this, and using mempty.

But, the (<>) is never used, and mostly meaningless for combining the actual annotation payloads.

The logical type class to use for this is Data.Default, but it is not part of the GHC library set.

What is the best way forward?

  • A. Keep it as it is
  • B. Use Data.Default, and add a copy of it in GHC somewhere
  • C. Create a new class playing the role of Data.Default.

I suspect option B may cause too many ecosystem knock-on effects, so the real options are A or C.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information