Re: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept

I suppose we could use the GHC20XX standards as a way to slowly course-correct. 1. Introduce -X@MeansTypeNamespaceOnly 2. Enable -X@MeansTypeNamespaceOnly as part of GHC2022 3. Let the ecosystem slowly adopt the change as they move to newer language standards But I think there would still be more questions to answer. 1. What becomes the new syntax for visibility specifiers? (I think Agda and Idris use {}?) 2. Do we really need visibility specifiers? (I wish the answer were no, but I think it's yes.) 3. If we do need visibility specifiers, do I then have to write `f {@Int}` to specify an invisible type argument? That's gross. So I'm netting out in the same place as Arnaud, somewhat uncomfortable with the proposal, but unable to come up with a better idea that doesn't compromise on expressiveness. I really do wish we could avoid the three ways to specify type arguments, but it seems like they're all necessary for different reasons.. On Fri, Oct 29, 2021, at 11:35, Spiwack, Arnaud wrote:

On Fri, Oct 29, 2021 at 5:16 PM Eric Seidel wrote:

...

In my mind the use of '@' as a visibility specifier is the inconsistency, as '@' has been the symbol for type application both in Core and Haskell for much longer than it has been used as a visibility specifier.

I agree with this. But how would you fix the current situation? `@` is used as a visibility specifier in the user language (well, it switches both visibility and grammar/namespace). If `@` is to switch only grammar/namespace, what do we make of all the `@` that have been written in the past half-dozen years?

/Arnaud