I think it makes a lot of sense to have a standard way for third-parties
to attach string-y information to Haskell source constructs. While it's
not strictly speaking necessary to standardize the syntax, doing
so minimizes the chance that tools overlap and hopefully reduces
the language ecosystem learning curve.

This sounds exactly like the existing ANN pragma, which is what I've wanted LiquidHaskell to move towards for a long time. What is wrong with using the ANN pragma?

As far as I understand it ANN's are not as generally useful as pure pragmas. For example I don't think you can attach an ANN to an import.*

Speaking of imports: would it be a viable idea to define and import pragmas on a source level? What I mean is something like this:

Option A:

-- | In, say, Language.Lint.Pragma: | ------------------------

{-# PRAGMA LINT  LintSetting #-}     -- Tells GHC that the pragma "LINT" exists and optionally adds information for the type checker
{-# PRAGMA HLINT LintSetting #-}     -- Define as many as you want per tool
:

-- | At usage site: | ----------------------------------------

{-# IMPORT Language.Lint.Pragma #-}  -- Could also be more specific, like "USES_TOOL"
:
{-# LINT defaultLintSetting{ … } #-}
:

Option B:

-- | In Language.Lint.Pragma: | ------------------------------

{-# DEFINE LINT :: LintSetting #-}   -- Same as above, different choice of syntax
{-# ALIAS HLINT LINT #-}             -- As long as I'm inventing syntax I might as well go a bit further
:

-- | At usage site: | ----------------------------------------

import Language.Lint.Pragma          -- Pragmas are imported implicitly, just like instances. An import is needed anyway if pragma type ≠ String and/or types are checked
:
{-# LINT defaultLintSetting{ … } #-}
:

Is that too complicated for tool users? Is that easier than {-# OPTIONS_GHC -Wno-pragma=HLINT #-}? Would it make preprocessing harder because imports would have to be parsed first? Could the "import" in option A be implicit if a tool is used via a GHC command line? I don't know enough about either the use of tools nor the implementation of ghc to answer this. But the idea looked like it might be a compromise where tool pragmas could be added outside the ghc source.

Cheers,
MarLinn

PS: * Why would I want to annotate imports? Because many of my experiments aren't bigger than one file. It would be nice if I could make them self-contained and "portable" between development devices. In other words the goal is to embed as much cabal data as possible into my one source file. I can add quite a few things via pragmas and a shebang already, but I haven't found a way to add the list of packages the code depends on in an elegant fashion. What I imagine is that I might annotate groups of imports with the package they come from, similar to what XPackageImports allows. The related project in my ever-growing backlog would be a shim that would extract info like this from annotations and pass it on to cabal. Such a tool probably wouldn't be widely used, so there should be no need to extend GHC for it. But it would be nice to have GHC check spelling and possibly type especially whenever I don't use my as-of-yet non-existent tool.

PPS: It feels like pragmas and Template Haskell might merge into one thing somewhere in the future. Might be worth contemplating that when designing features.