<div dir="ltr"><div>I still want to suspend my judgement.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 13, 2020 at 12:12 PM Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com">trupill@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>
        <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" target="_blank">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" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
        </blockquote>
    </div>
</div>
    
</div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>