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