[ghc-steering-committee] #270: Support pun-free code, recommendation: accept

[Tom Harding]

Whew! Finally caught up with the PR discussion.

I agree with Simon: I don’t think adding style warnings is too dramatic a change, and my experience of introducing people to Haskell has involved a lot of confusion around punning, so I think discouraging punning is probably a good idea.

I do also like the import syntax, though, as an idealist, I am hoping that it can eventually be deprecated (once enough code is free of bad puns). Until then, I think this is a nice extra bit of clarity. As someone who habitually decorates everything with explicit forall, standalone kind signatures, explicit deriving strategies, and so on… well, I’m always a fan of extra clarity :-)

In short: I like this, and I’m in favour of acceptance.

Cheers,
Tom

> On 29 Jan 2022, at 15:41, Vitaly Bragilevsky <bravit111 at gmail.com> wrote:
> 
> Dear Committee,
> 
> Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov.
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/270
> 
> https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md
> 
> This proposal was heavily revised since Iavor recommended rejection.
> As of now, it is quite thin suggesting just a couple of things:
> - warnings for the code with panning (understood as using same names
> for both types and values)
> - a syntax change for import declarations to reflect which names
> (types or values) are actually imported when importing from libraries
> relied on punning.
> 
> The first change promotes a new style of writing Haskell code without
> distinguishing types and values and having a single unified namespace.
> We are already on that road anyway and I don't see any reason not to
> support this.
> 
> The second change allows using an old style with punning. It could
> lead to doubling import declarations, but I don't think that this is
> really a problem.
> 
> I think the proposal is mature enough so I recommend acceptance.
> 
> We can also decide on the actual word used in import declarations
> (data, value, or pattern). I personally prefer value, but I don't see
> this issue as something important.
> 
> Vitaly
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee