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

[Adam Gundry]

I'm broadly in favour of accepting the proposal. I realise the history 
is complex here, so I don't think we should ask anyone to rewrite things 
further, though in general it would be nicer to have separate proposals 
for -Wpuns/-Wpun-bindings (which is unambiguously fine) and for the 
changes to imports (which as Joachim points out raise issues).

I'm a bit concerned that the proposal does not motivate or specify 
-Wpattern-namespace-qualified very well.


On 08/12/2022 08:33, Joachim Breitner wrote:
> ...
> 
> This gives us (at least) these options:
> 
> 1. Leave ExplicitNamespaces alone, add ExplicitNamespaces to GHC2023,
>     introduce one or two new extensions for the newer changes.
> 2. Extend ExplicitNamespaces, and don’t add it already to GHC2023,
>     disregarding issue #551.
> 3. Add ExplicitNamespaces to GHC2023, and still add it to GHC2023,
>     arguing that GHC20xx allows more liberal (backward-compatibile)
>     changes than, say, Haskell2010 would allow.
> 
> Certainly 1 is the least bold move. I am not sure what the best way
> forwards is, and welcome other opinions.

I would prefer a variant of 1: allow "data" as a keyword in import lists 
under ExplicitNamespaces, but make the other changes under other extensions.

As I've said previously, I have a general preference for multiple small, 
orthogonal extensions rather than changing existing extensions to add 
unrelated features that happen to be in similar territory. I realise 
this is controversial, of course.

Cheers,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England