
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hooray Sebastian!<div class=""><br class=""></div><div class="">Somehow, I knew cluing you into this conundrum would help find a solution. The approach you describe sounds quite plausible.</div><div class=""><br class=""></div><div class="">Yet: types *do* matter, of course. So, I suppose the trick is this: have the COMPLETE sets operate independent of types, but then use types in the PM-checker when determining impossible cases? And, about your idea for having pattern synonyms store pointers to their COMPLETE sets: I think data constructors can also participate. But maybe there is always at least one pattern synonym (which would be a reasonable restriction), so I guess you can look at the pattern-match as a whole and use the pattern synonym to find the relevant COMPLETE set(s).</div><div class=""><br class=""></div><div class="">Thanks for taking a look!</div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 31, 2020, at 4:23 PM, Sebastian Graf <<a href="mailto:sgraf1337@gmail.com" class="">sgraf1337@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">Hi Richard,</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenberg <<a href="mailto:rae@richarde.dev" class="">rae@richarde.dev</a>>:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sebastian,<br class="">

<br class="">

I enjoyed your presentation last week at ICFP!<br class=""></blockquote><div class=""><br class=""></div><div class="">Thank you :) I'm glad you liked it!<br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

This thread (<a href="https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms" rel="noreferrer" target="_blank" class="">https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms</a>) played out before you became so interested in pattern-match coverage. I'd be curious for your thoughts there -- do you agree with the conclusions in the thread?<br class=""></blockquote><div class=""><br class=""></div><div class="">I vaguely remember reading this thread. As you write <a href="https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms#post9" class="">there</a></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">And, while I know it doesn't work today, what's wrong (in theory) with<br class=""><br class="">{-# COMPLETE LL #-}<br class=""><br class="">No types! (That's a rare thing for me to extol...)<br class=""><br class="">I feel I must be missing something here.</div></blockquote><div class=""><br class=""></div><div class="">Without reading the whole thread, I think that solution is very possible. The thread goes on to state that we currently attach COMPLETE sets to type constructors, but that is only an implementational thing. I asked Matt (who implemented it) somewhere and he said the only reason to attach it to type constructors was because it was the easiest way to implement serialisation to interface files.</div><div class=""><br class=""></div><div class="">The thread also mentions that type-directed works better for the pattern-match checker. In fact I disagree; we have to thin out COMPLETE sets all the time anyway when new type evidence comes up, for example. It's quite a hassle to find all the COMPLETE sets of the type constructors a given type can be "represented" (I mean equality modulo type family reductions here) as. I'm pretty sure it's broken in multiple ways, as <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/18276" class="">#18276</a> points out.<br class=""></div></div><div class="gmail_quote"><br class=""><div class="">Disregarding a bit of busy work for implementing serialisation to interface files, it's probably far simpler to give each COMPLETE set a Name/Unique and refer to them from the pattern synonyms that mention them (we'd have to get creative for orphans, though). The relation is quite like between a type class instance and the type in its head. A more worked example is here: <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/18277#note_287827" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/18277#note_287827</a></div><div class=""><br class=""></div><div class="">So, it's on my longer term TODO list to fix this.<br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br class="">

My motivation for asking is <a href="https://github.com/conal/linalg/pull/54" rel="noreferrer" target="_blank" class="">https://github.com/conal/linalg/pull/54</a> (you don't need to read the whole thing), which can be boiled down to a request for a COMPLETE pragma that works at a polymorphic result type. (Or a COMPLETE pragma written in a module that is not the defining module for a pattern synonym.) <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/14422" rel="noreferrer" target="_blank" class="">https://gitlab.haskell.org/ghc/ghc/-/issues/14422</a> describes a similar, but even more challenging scenario.<br class=""></blockquote><div class=""><br class=""></div><div class="">I'll answer in the thread. (Oh, you also found #14422.) I think the approach above will also fix #14422.<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br class="">

Do you see any ways forward here?<br class=""></blockquote><div class="">. <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br class="">

Thanks!<br class="">

Richard</blockquote><div class=""><br class=""></div><div class="">Maybe I'll give it a try tomorrow. <br class=""></div></div></div>

</div></blockquote></div><br class=""></div></body></html>