<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite"
cite="mid:1539719290.3266129.1544285568.4036F292@webmail.messagingengine.com">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
<br>
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.*<br>
<br>
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:<br>
<h4>Option A:</h4>
<pre style="background:#eee; margin-left:2em">-- | 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
:
</pre>
<pre style="background:#eee; margin-left:2em">-- | At usage site: | ----------------------------------------
{-# IMPORT Language.Lint.Pragma #-} -- Could also be more specific, like "USES_TOOL"
:
{-# LINT defaultLintSetting{ … } #-}
:
</pre>
<h4>Option B:</h4>
<pre style="background:#eee; margin-left:2em">-- | 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
:</pre>
<pre style="background:#eee; margin-left:2em">-- | 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{ … } #-}
:</pre>
<p>Is that too complicated for tool users? Is that easier than <tt>{-#
OPTIONS_GHC</tt><tt> -Wno-pragma=HLINT #-}</tt>? 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.</p>
<p>Cheers,<br>
MarLinn</p>
<p><font size="-1">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</font><font size="-1"><font
size="-1"> used</font>, 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 <i>don</i><i>'t</i> use my
as-of-yet non-existent tool.</font></p>
<p><font size="-1">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.</font><br>
</p>
</body>
</html>