<div dir="ltr"><div>I find myself in agreement with Richard's comment on Github. Even if we consider that a new language should implement the proposal (I'm not sure that I do, but I'm willing to be convinced), I don't think the difference with the current implementation is worth the change (and, in practice, maintaining both approaches).</div><div><br></div><div>Vitaly, you initially recommended acceptance, maybe you want to argue further to try and change our minds?</div><div><br></div><div>John hasn't replied to Richard's comment on Github yet. Let's see what he thinks about this, too.<br></div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 7, 2021 at 9:59 AM 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=""><div dir="ltr">
I am against this proposal, I would say that even in spirit. There are several reasons for this:</div><div dir="ltr">- there’s still a lot of work going on on this same topic (there have been several papers on the matter in the last 5 years), so I fear that writing down a spec now would either: (1) deter others from trying, or (2) make those new rules under a flag like `ExtendedIncompletePatterns` which everybody will just blindly enable (like `FlexibleInstances` in the past);</div><div dir="ltr">- for that reason, I think that incomplete patterns belong to the warning/error mechanism, something which can point to potential problems or unexpected behaviours. As part of the development of GHC those errors and warnings get better;</div><div dir="ltr">- the extension is “too local”: it tells you that you’ve missed a case in *this* `case` statement. Yet, you can get pattern match errors if you use a function imported somewhere else which doesn’t account for that case.</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr">Alejandro<br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El 29 may 2021 13:31:13, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> escribió:<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 dir="ltr"><div dir="ltr"><div>I would support this, but only if <br></div><div>1. we specify precisely exactly which pattern matches are accepted, and</div><div>2. GHC accepts only those patterns when NoIncomplete is enabled</div><div><br></div><div>That is, it would certainly be a subset of -Wincomplete-patterns. No cleverness, no adding extra magic to accept more programs with each release. The point of a spec is to say exactly which programs are accepted, in such a way that different implementations can implement the feature consistently - one implementation is not allowed to accept more programs, otherwise there's no point in having a definition of the feature.</div><div><br></div><div>If we don't want to do this (and I suspect it would be annoying to implement), then I think -Werror is the best alternative.<br></div><div><br></div><div>Cheers</div><div>Simon<br> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 26 May 2021 at 13:33, Vitaly Bragilevsky <<a href="mailto:bravit111@gmail.com" target="_blank">bravit111@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 dir="ltr"><div>Dear Committee, <br></div><div><br></div><div>We have been discussing the NoIncomplete pragma proposal by John Ericson for quite a long time. I think it's ready for acceptance.<br></div><div><br></div><div>The proposal itself: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/351" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/351</a></div><div>The rendered version: <a href="https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-incomplete.rst" target="_blank">https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/proposals/0000-no-incomplete.rst</a></div><div><br></div><div>The proposal aims to introduce the NoIncomplete pragma that would prohibit programs which have a source of incompleteness (in patterns, in methods) in them. There is also the new -fdefer-incompleteness-errors flag.</div><div><br></div><div> I think this feature comes quite handy in education. I'd use it all the time with my students.</div><div><br></div><div>Please comment here or in the GitHub thread if you see any problems with this proposal.</div><div><br></div><div>Vitaly<br></div><div><br></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></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" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</div>
</blockquote>
</div>
</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>