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

[Arnaud Spiwack]

As it currently stands, it seems to me that the proposal is pretty modest.
I'm in favour of the proposal, provided that the technical details are
resolved to Joachim satisfaction.

On Thu, 8 Dec 2022 at 09:33, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> (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/
>
> _______________________________________________
> 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/20221208/d8090d97/attachment.html>