<div dir="ltr"><div dir="ltr">On Tue, Dec 8, 2020 at 8:54 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">No. If we have GADTs and/or TypeFamilies, then we should absolutely have MonoLocalBinds -- GADTs and TypeFamilies are wonky without MonoLocalBinds. I'd prefer not to have any of them on by default.</div></blockquote><div><br></div><div>Do we agree that this is not tenable in the long term? At some point, GADTs and TypeFamilies need to be in by default. When is that horizon? For context, these features have been with us for 12 years (since GHC 6.8.1). And quite stable in the last 6 years. They are not going anywhere, they are very widely used.</div><div><br></div><div>Just as much, I'd say MonoLocalBinds really wants to be the default (supporting `NoMonoLocalBinds` at all probably has some non-trivial implementation costs, I would not be sad to see this go, even if it's a bit hard to get rid of in the current state because it does mean breaking compatibility with Haskell98 and Haskell2010, in fact, we still support `DatatypeContext` at the cost of code).</div><div><br></div><div>Maybe GHC2021 shouldn't have these (it's not my opinion, but it's arguable). Since the value of GHC2021 is “conservatism” (then again, we seem to be adding in StandaloneKindSignatures and NamedFieldPuns, which do not sound very conservative to me). But then, they are the first two extensions that should be considered for GHC2022. Do we agree on this? Or would you rather see these stay in their standalone extensions forever? (which I would find, personally, rather alarming)<br></div><div><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 style="overflow-wrap: break-word;">Exactly, yes. I am strongly against PartialTypeSignatures as an extension, as users should have to opt into accepting partially-written programs.</div></blockquote><div><br></div><div>How is a partial type signature a partially-written program? Does the absence of type signature on a binding make a program partially written? Because a partial type signature is more than no signature at all, so it should be considered less partial at least.</div><div><br></div><div>Plus, partial type signatures give a warning (which, I've argued before, is probably more than you actually want cf <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/16220">https://gitlab.haskell.org/ghc/ghc/-/issues/16220</a>).</div><div><br></div><div>I don't know that we want PartialTypeSignature this time around. And there may be reason to never want them. But I'd say “users should have to opt into accepting partially-written programs” is not one of them.</div><div><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 style="overflow-wrap: break-word;"><span style="float:none;display:inline"><div>With NamedWildCards, we get</div></span><div><span style="float:none;display:inline"><div><br></div><div><div></div><blockquote type="cite"><div>Bug.hs:5:8: error:</div><div>    • Found type wildcard ‘_a’ standing for ‘Bool’</div><div>      To use the inferred type, enable PartialTypeSignatures</div><div>    • In the type signature: foo :: _a -> _a</div></blockquote><br></div><div>I think that prefixing a variable name with an underscore is a convenient, lightweight way of asking GHC to tell me what a type should be.</div></span></div></div><br></blockquote><div><br></div><div>On the other hand, I think that I agree with this, and that I will change my vote. <br></div></div></div>