<html><body>
<div dir="ltr">
<div dir="ltr">Hi,</div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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).</div><div dir="ltr"><br></div><div dir="ltr">Alejandro</div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 11 Nov 2020 at 22:41:55, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com">iavor.diatchki@gmail.com</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</blockquote>
</div>
</div>
</body></html>