<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I think this is a good point, Vlad, but I think the semantics of Unsatisfiable and TypeError @Constraint are actually different.<div class=""><br class=""></div><div class="">Specifically, suppose we have an unsolved [W] (F a0 ~ Dict (Unsatisfiable "blah")) constraint. That will report a "failure to unify" error, muttering about an ambiguous a0, most likely. On the other hand <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">[W] (F a0 ~ Dict (TypeError @Constraint "blah")) will spit out "blah". I suppose we could say, by fiat, that `TypeError @Constraint` has the semantics this proposal gives to Unsatisfiable, and then `TypeError @anything_other_than_constraint` has its usual (underspecified) semantics. This would a little unstable at the edges (when we might or might not have simplified a variable to Constraint), but that's OK, because the instability is only around the wording of an error message.</span></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">I still favor having a separate Unsatisfiable. Use TypeError when you are writing a partial type family that looks total and need to fill in the missing case. Use Unsatisfiable when you have a constraint.</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Writing all this makes me wonder, though, about the relationship between Unsatisfiable and Warning. I will post on GitHub.</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Richard</span></font></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 27, 2021, at 10:33 AM, Vladislav Zavialov (int-index) <<a href="mailto:vlad.z.4096@gmail.com" class="">vlad.z.4096@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I’m in favor of the proposal overall, but if we include the ‘Warning’ machinery, I’d like to see Richard’s suggestion about a (flag :: Symbol) parameter, so that users can enable and disable custom warnings.<br class=""><br class="">Also, I don’t understand why we need a separate ‘Unsatisfiable’ class when we could reuse ’TypeError’ instantiated at kind ‘Constraint’. Adam lists this option in the Alternatives, but I wish it had a more detailed explanation why this is not possible. Just think of the API we are going to end up with:<br class=""><br class="">* TypeError<br class="">* Unsatisfiable<br class="">* Warning<br class=""><br class="">How come ‘Warning’ is a constraint like ‘Unsatisfiable’ rather than like ’TypeError’? I agree that each piece here makes sense individually, but we should also consider a more holistic approach to API design. Reusing ’TypeError’ is certainly tempting.<br class=""><br class="">- Vlad<br class=""><br class=""><blockquote type="cite" class="">On 27 Oct 2021, at 12:01, Tom Harding <<a href="mailto:i.am.tom.harding@gmail.com" class="">i.am.tom.harding@gmail.com</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br class="">Firstly, apologies for the radio silence - I’ve apparently been having some undiscovered email trouble (perhaps even since joining the committee), and so I’m now going to be using my usual, and hopefully far more reliable, email address.<br class=""><br class="">With that said, I’d like to recommend proposal #433 for acceptance. The proposal does a good job of outlining the difference between this and the current TypeError mechanism, and I think the case is well justified. Certainly, the ability to bypass fundep checks in error case “instances” immediately brought to mind a handful of places in my own libraries that could benefit from this check.<br class=""><br class="">I think the thread already contains a lot of committee activity, but I welcome any further comments!<br class=""><br class="">Thanks,<br class="">Tom<br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></blockquote><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></div></blockquote></div><br class=""></div></body></html>