[ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept

[Vladislav Zavialov]

If you read the "Resolved Syntax Tree" section of #281, you can see the
contortions it has to go through to support puns. It's very nuanced! I can
easily imagine future users of RequiredTypeArguments struggle with type
errors because they wanted to use a name from one namespace but this
elaborate system selected a name from another namespace. -Wpuns would
prevent this from happening: it can help identify namespace ambiguities and
avoid them.

It is mainly for this reason that I vote +1.

And I'm happy to see the disclaimer that it is not "bad style" to use puns.
What is considered good or bad often depends on context. In a module with
RequiredTypeArguments, I would prefer to see -Wpuns enabled. In a module
without it, I don't particularly care.

Vlad

On Mon, Dec 5, 2022 at 9:33 PM Chris Dornan <chris at chrisdornan.com> wrote:

> Hi all,
>
> I have been assigned to shepherd 'Proposal #270: Support pun-free code’
> and this is my second attempt to reach a conclusion (see below for for my
> original encapsulation of the proposal).
>
> As I said, my outstanding concern was that some could see this proposal as
> a green-lighting a general move against the use of these puns in general
> Haskell code as ‘bad style. The author has now clarified in the proposal
> that it should not be seen in this light.
>
> Unless anyone has any outstanding objections I suggest the we accept the
> proposal — or at least hold an up-and-down vote to resolve whether we are
> going to accept the proposal or not.
>
> I vote yes to accepting this proposal.
>
> Chris
>
> —
>
> My original summary:
>
> Proposal text:
> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md
>
> Proposal discussion:
> https://github.com/ghc-proposals/ghc-proposals/pull/270
>
> The proposal helps manage @data T = T@ style definitions that use the
> same name for type and data constructors.
>
> It introduces -Wpuns and -Wpun-bind to warn about puns at usage and
> binding sites, respectively, and adds qualified import syntax for importing
> selectively into the data and type name spaces:
>
>  import Data.Proxy type qualified as T   -- import only the type namespace
>  import Data.Proxy data qualified as D   -- import only the data namespace
>
> As the low number indicates the proposal has been around for a while and
> the author has an implementation PR:
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044.
>
> The most active discussion point was Simon’s observation that this
> extension introduces a ‘fork’ in the language:
> https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565.
> (See Simon’s comment at the link for an explanation of the Haskell language
> fork idea.)
>
> There is a long tradition of using data/type constructor puns (older than
> Haskell itself) and many people will consider it good style (I certainly
> do), while others do not, and they will benefit from tools to help manage
> and limit their use. So, notwithstanding the fork-like nature of the
> proposal, because it is not very intrusive (some warnings with finer
> control of qualified imports), and it is helping folks to establish a
> subset that they are maintaining anyway, I am minded to accept this
> proposal — though it was close.
>
> My sole concern is that it could give rise to contentious pressure on the
> wider Haskell community to embrace the subset. To (avoiding) this end, I
> suggest that we include wording in the user guide section documenting this
> extension to the effect that there is no consensus on the desirability or
> otherwise of the punful code the extension seeks to address.
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221206/ada2e4b7/attachment.html>