<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="">I'm afraid I don't understand what your new syntax means. And, while I know it doesn't work today, what's wrong (in theory) with<div class=""><br class=""></div><div class="">{-# COMPLETE LL #-}</div><div class=""><br class=""></div><div class="">No types! (That's a rare thing for me to extol...)</div><div class=""><br class=""></div><div class="">I feel I must be missing something here.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 25, 2018, at 12:24 PM, Sylvain Henry <<a href="mailto:sylvain@haskus.fr" class="">sylvain@haskus.fr</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    <pre class="moz-quote-pre" wrap="">> In the case where all the patterns are polymorphic, a user must
> provide a type signature but we accept the definition regardless of
> the type signature they provide. </pre><p class="">Currently we can specify the type *constructor* in a COMPLETE
      pragma:</p>
    <pre class=""><tt class="">pattern J :: a -> Maybe a</tt><tt class="">
</tt><tt class="">pattern J a = Just a</tt><tt class="">
</tt><tt class="">
</tt><tt class="">pattern N :: Maybe a</tt><tt class="">
</tt><tt class="">pattern N = Nothing</tt><tt class="">
</tt><tt class="">
</tt><tt class="">{-# COMPLETE N, J :: Maybe #-}</tt><tt class="">
</tt></pre><p class=""><br class="">
    </p><p class="">Instead if we could specify the type with its free vars, we could
      refer to them in conlike signatures:</p>
    <pre class=""><span class="p">{-# COMPLETE N, [</span><span class="p"><span class="kt"> J</span></span><span class="p"><span class="kt"></span> <span class="ow">::</span> a -> Maybe a ] :: Maybe a #-}</span></pre><p class="">The COMPLETE pragma for LL could be:<span class="p"></span><br class="">
      <span class="p"></span></p>
    <pre class=""><pre class=""><span class="p">{-# COMPLETE [</span><span class="p"><span class="kt"> LL</span> <span class="ow">::</span> <span class="kt">HasSrcSpan</span> a <span class="ow">=></span> <span class="kt">SrcSpan</span> <span class="ow">-></span> <span class="kt">SrcSpanLess</span> a <span class="ow">-></span> a ] :: a #-}
</span></pre></pre>
    <br class=""><p class="">I'm borrowing the list comprehension syntax on purpose because it
      would allow to define a set of conlikes from a type-list (see my
      request [1]):<span class="p"></span><br class="">
      <span class="p"></span></p>
    <pre class=""><pre class=""><span class="p">{-# COMPLETE [</span><span class="p"><span class="kt"> V</span> <span class="ow">::</span> </span><span class="p"><span class="p">(c :< cs) => c -> Variant cs</span>
             | c <- cs
             ] :: Variant cs
  #-}</span>
</pre>
>    To make things more formal, when the pattern-match checker
> requests a set of constructors for some data type constructor T, the
> checker returns:
>
>    * The original set of data constructors for T
>    * Any COMPLETE sets of type T
>
> Note the use of the phrase <b class="moz-txt-star"><span class="moz-txt-tag">*</span>type constructor<span class="moz-txt-tag">*</span></b>. The return type of all
> constructor-like things in a COMPLETE set must all be headed by the
> same type constructor T. Since `LL`'s return type is simply a type
> variable `a`, this simply doesn't work with the design of COMPLETE
> sets.

</pre><p class="">Could we use a mechanism similar to instance resolution (with
      FlexibleInstances) for the checker to return matching COMPLETE
      sets instead?</p>
    <pre class="">
--Sylvain


[1] <a class="moz-txt-link-freetext" href="https://mail.haskell.org/pipermail/ghc-devs/2018-July/016053.html">https://mail.haskell.org/pipermail/ghc-devs/2018-July/016053.html</a>
<span class="p"></span></pre>
  </div>

_______________________________________________<br class="">ghc-devs mailing list<br class=""><a href="mailto:ghc-devs@haskell.org" class="">ghc-devs@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br class=""></div></blockquote></div><br class=""></div></body></html>