1. What prevents us from adding `NamedFieldPuns` as a proper constructor for
the `Extension` type and in principle remove `RecordPuns`? Backward
compatibility I assume?
You mean, essentially, rename `LangExt.RecordPuns` to `NamedFieldPuns`.
I’d be fine with that. There might be back-compat issues, but only with other
plugins, and probably with vanishingly few of them. Grep in Hackage!
Simon
From: ghc-devs <ghc-devs-boun...@haskell.org> On Behalf Of Alfredo Di Napoli
Sent: 06 July 2021 10:14
To: Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org>
Subject: Can NamedFieldPuns be added to
`GHC.LanguageExtensions.Types.Extension`?
Dear all,
As some of you might know, for the past few months I have been working on
changing GHC's diagnostic messages from plain SDocs to richer Haskell types.
As part of this work, I have added a mechanism to embed hints into diagnostics,
defined in `GHC.Types.Hint` in `HEAD`. One of the main workhorse of this
`GhcHint` type is the `SuggestExtension LangExt.Extension` constructor, which
embeds the extension to enable to use a particular feature. The
`LangExt.Extension` type comes from `GHC.LanguageExtensions.Types`, and up
until now there has always been a 1:1 mapping between the language pragma for
the extension and the type itself.
Today I was working on turning this error into a proper Haskell type:
badPun :: Located RdrName -> TcRnMessage
badPun fld = TcRnUnknownMessage $ mkPlainError noHints $
vcat [text "Illegal use of punning for field" <+> quotes (ppr fld),
text "Use NamedFieldPuns to permit this"]
I was ready to yield a `SuggestExtension LangExt.NamedFieldPuns` when I
discovered that there is no `NamedFieldPuns` constructor. Rather, there is a
`RecordPuns` , which refer to a deprecated flag, and we simply map
`NamedFieldPuns` back to it in `GHC.Driver.Session`:
...
depFlagSpec' "RecordPuns" LangExt.RecordPuns
(deprecatedForExtension "NamedFieldPuns"),
...
flagSpec "NamedFieldPuns" LangExt.RecordPuns,
...
This is problematic for the `GhcHint` type, because now if I was to yield
`SuggestExtension LangExt.RecordPuns` to the user, I could still pretty-print
the suggestion to turn `RecordPuns` into `NamedFieldPuns`, but this means that
IDEs or third-party library would have access to the
"raw" Haskell datatype, and at that point they will be stuck with a suggestion
to enable a deprecated extension! (or best case scenario they will have to
transform the suggestion into something more sensible, which partially defeats
the point of this refactoring work I have been doing).
I am not sure this behaviour is unique for just `NamedFieldPuns`, but my
question is:
1. What prevents us from adding `NamedFieldPuns` as a proper constructor for
the `Extension` type and in principle remove `RecordPuns`? Backward
compatibility I assume?
Many thanks,
Alfredo
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
