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

Tue Jul 13 07:08:20 UTC 2021

Hello all,

I am happy to see engagement on this issue. I didn't read Ed's and
Richard's replies until now, but I have indeed explored the pattern synonym
solution, which I have materialised in a MR here:

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6156

As I say in the MR description, the only small downside is the beefy
`COMPLETE` pragma, but we gain the possibility of deprecating the extension
a bit more explicitly, which is nice. Feedback welcome! :)

Thanks,

Alfredo

On Mon, 12 Jul 2021 at 17:08, Edward Kmett <ekmett at gmail.com> wrote:

> There's always pattern synonyms as an option for cases like this, free of
> backwards compat issues.
>
> -Edward
>
> On Tue, Jul 6, 2021 at 3:00 AM Alfredo Di Napoli <
> alfredo.dinapoli at gmail.com> wrote:
>
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210713/296d27b7/attachment.html>