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
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee