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

[Joachim Breitner]

(replying to the whole list, full quote)

Am Donnerstag, dem 08.12.2022 um 11:23 +0300 schrieb Vladislav
Zavialov:
> I agree with your observation that namespaced imports are somewhat
> different from simply specifying the namespace of a single name, so
> they could be separated into their own extension. But if that is the
> reasoning that we choose to follow, then the changes in #281 should
> *definitely* go into their own extension: they affect not just names
> but entire expressions and patterns, including their grammar (not
> just namespacing).
> 
> The only reason the changes in #270 and #281 are included in
> ExplicitNamespaces is to reduce the amount of language flags. If you
> prefer fine-grained control and immutable extensions, then both of
> those changes need separate flags for them.
> 
> So, if we are consistent, we have two options:
> 1. Include changes in #270 and #281 in ExplicitNamespaces on the
> grounds that they include explicitly specify a namespace (even though
> that is not the only thing they do)
> 2. Create separate language extension flags: NamespacedImports and
> TypesInExpressions (names to be discussed)
> 
> I happen to prefer (1), and that is the approach that the proposals
> currently follow, but I am not opposed to (2) either.

I don’t prefer fine-grained flags per se. In fact, my ideal world is
one perfect language with no flags :-). So I think I’d prefer all under
ExplicitNamespaces as well, and I think the only reason I am hesitant
is that I believe the old ExplicitNamespaces should have been in
GHC2021, so it should be in GHC2023, and am unsure if the
(comprehensive) ExplicitNamespaces should be there.

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.

Cheers,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/