I still want to suspend my judgement.

The proposal is much better than the first iteration that I've read. It's clear and precise (except maybe the Alternative section which is light in details). I asked for several clarifications on the Proposal's thread.

I'm still sympathetic to the motivation, and rather unconvinced by the proposed solution. I'm confident that we will eventually accept some version of this proposal (and even if this one gets rejected, a lot of the material in it will be useful for the next iteration of the proposal). I'm not sure that we have found the right approach yet. But I am not ready to discard this proposal wholesale either.

This is turning into a pretty difficult conversation, I'm afraid, and I'm sorry for Vladislav who has to bear the brunt of the burden. But I think that it's a conversation worth having, and it is time well spent for the community.

/Arnaud

On Fri, Nov 13, 2020 at 12:12 PM Alejandro Serrano Mena <trupill@gmail.com> wrote:
Hi,
I agree with Iavor’s points. The proposal is quite big, and there’s a lot on it about implementation, but not a simple user-facing spec.

In addition to that, I would lean towards rejection because I think giving another meaning to `f Int 5` depending on the the type of `f` — if f doesn’t have a `forall a ->` then `Int` is thought as a constructor, otherwise it’s the type — makes the language too ambiguous. I thought that the language leaned more towards explicitness because DataKinds punning was removed (so I really need to write ‘Int to get the promoted Int constructor) and type applications required @ too.

Another point which is discussed in the proposal not in detail, but I think it’s central to this discussion is: is @ a visibility-override or a other-namespace-symbol. Right now both are conflated by TypeApplications, but personally I think it more of it as the latter: if I am in “term-land” and I want to switch to “type-land”, then I use @. In essence, I think we should keep the two-namespaces separate (we could say I prefer a Haskell-2 instead of a Haskell-1).

Alejandro

On 11 Nov 2020 at 22:41:55, Iavor Diatchki <iavor.diatchki@gmail.com> wrote:
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee