I'm in support. I'm supporting this proposal so that Haskell can be a friendly home both for those who like punning and those who don't. I'm not taking a position on which is "better", but I don't want to stand in the way of those who do have a view and want to write in that style. Simon On Mon, 5 Dec 2022 at 18:33, Chris Dornan 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-...

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-5361155.... (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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, generally in favor; these new warnings shoudn’t do harm and are hopefully useful to some. But I have a technical issue (sorry for being so late with that): I note that this proposal extends -XExplicitNamespaces, which so far can be used to distinguish type from term operators in export and import lists, by allowing them to be prefixed with `type` (but not `data`!), as in: import N( f, type (++) ) https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/explicit_name... The new extension now extends this extension the import qualified Foo data as FD import qualified Foo type as FT forms to “filter” imports by namespace. A few points: * It seems to be inconsistent to allow both `type` and `data` in the  filtered-import, but as a qualifier on individual only `type`. Should we allow the use of `data` in import/export lists as well? import N(f, type (++), data (+)) * As discussed in https://github.com/ghc-proposals/ghc-proposals/issues/551, -XExplicitNamespaces, which is quite old and is implied by  -XTypeOperators which is implied by -XGHC2021 probably ought to have been in GHC2021 as well, and I’d like to include it in GHC2023 (if  that exists) to fix that (see #559). But that feels inappropriate if we extend that extension in this way. We could side-step that issue if we put he new forms in their own language extension (maybe -XNamespacedImport)? WDYT? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/