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

[Joachim Breitner]

Hi,

Am Donnerstag, dem 08.12.2022 um 10:43 +0300 schrieb Vladislav
Zavialov:
> #281 also modifies ExplicitNamespaces to enable inline "type"
> qualifiers in expressions. Do you want a separate extension for that
> also?

ah, I knew we had that somewhere! Thanks for reminding me!

So with #281, I can use inline `type` everywhere where I refer to a
name? Or only in expressions? Reading the spec I can only use them in
expressions – why not in types? And is there no dual use-case to refer
to data in types, e.g. with promoted types?

My current gut feeling is that there could be a simple unified
“explicit namespace qualifier” that I can use essentially everywhere
when I want to be explicit which Foo I mean – expressions, types,
import lists, export lists, INLINE pragmas. ExplicitNamespaces sounds
like the natural name for that extensions, and nicely extends it.

I am unsure if it is wise to extend ExplicitNamespaces that way and at
the same time advocate for its inclusion in GHC20xx. This depends a bit
on how bold we want to be with GHC20xx. A conservative approach is to
find a new name for the “comprehensive” extension. I expect that
extension would then subsume the changes in #281.


The extension to imports in #270 has a slightly different feel to it –
you are not qualifying a name here, but you are really filtering all 
imported names. I think putting that into its own extension makes sense
for two reasons:

 * It decouples these discussions for now.
 * It may be that -XNamespacedImport turns out to be not that useful
   when instead you can disambiguate at the occurrence or in an
   explicit import list using  (comprehensive) ExplicitNamespaces, and
   one possible future may be that that style will be more common.
   Then we may want to make one, but not the other, the default.

Cheers,
Joachim


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