Can NamedFieldPuns be added to `GHC.LanguageExtensions.Types.Extension`?

[Alfredo Di Napoli]

Hello Simon,

Yes, renaming and perhaps keeping `RecordPuns` as a pattern synonym to not
break backward-compat, if that's feasible to define as we are in
`ghc-boot-th` here. Not sure if `PatternSynonyms` and `COMPLETE` would be
available there.

I am not sure how many libs that depend on the ghc API would break (I
haven't grepped on Hackage yet), but that might tip the benefits/troubles
ratio towards keeping the status quo.

This is not a "problem" I have to solve today, and it might not be
considered a problem by others (just an inconsistency I guess): as a
colleague of mine pointed out, GHC is not necessarily "lying" here. It's
still the same underlying extension, it just happens that there are two
names that refer to it.

Perhaps I could think about adding to `GhcHint` some kind of mapping which
would give to IDEs or third-party libs the correct extension name given an
input `LangExt.Extension`, the problem then becomes making sure that we
keep this mapping in sync with the information contained in
`GHC.Driver.Session`.

I will let it simmer.

Thanks!

A.

On Tue, 6 Jul 2021 at 11:19, Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> 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-bounces at haskell.org> *On Behalf Of *Alfredo Di
> Napoli
> *Sent:* 06 July 2021 10:14
> *To:* Simon Peyton Jones via ghc-devs <ghc-devs at 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210706/05092823/attachment.html>