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

[Eric Seidel]

I suppose we could use the GHC20XX standards as a way to slowly course-correct.

1. Introduce -X at MeansTypeNamespaceOnly
2. Enable -X at 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 <eric at seidel.io> 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