Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms

[Richard Eisenberg]

In a rare move, I disagree with Ryan here.

Why don't we want LL to be abstract? I personally don't want to be thinking of some desugaring to a view pattern when I say LL. I want just to be pattern matching. Is there a reason we can't extend COMPLETE pragmas to cover this case?

Richard

> On Oct 25, 2018, at 9:30 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> 
> The fact that `LL` can't be used in a COMPLETE pragma is a consequence
> of its current design. Per the users' guide [1]:
> 
>    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 *type constructor*. 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.
> 
> But to be perfectly honest, I feel that trying to put `LL` into a
> COMPLETE set is like putting a square peg into a round hole. The
> original motivation for COMPLETE sets, as given in this wiki page [2],
> is to support using pattern synonyms in an abstract matter—that is, to
> ensure that users who match on pattern synonyms don't have any
> internal implementation details of those pattern synonyms leak into
> error messages. This is well and good for many use cases, but there
> are also many use cases where we don't *care* about abstraction.
> Sometimes, we simply define a pattern synonym to be a convenient
> shorthand for a complicated pattern to facilitate code reuse, and
> nothing more.
> 
> `LL` is a perfect example of this, in my opinion. `LL` is simply a
> thin wrapper around the use of `decomposeSrcSpan` as a view pattern.
> Trying to put `LL` into a COMPLETE set is silly since our intention
> isn't to hide the implementation details of decomposing a `SrcSpan`,
> but rather to avoid the need to copy-paste `(decomposeSrcSpan -> (m ,
> s))` in a bazillion patterns. Correspondingly, any use of `LL` ought
> to be treated as if the `(decomposeSrcSpan -> (m , s))` pattern were
> inlined—and from the pattern-match coverage checker's point of view,
> that *is* exhaustive!
> 
> What's the moral of the story here? To me, this is a sign that the
> design space of pattern synonym coverage checking isn't rich enough.
> In addition to the existing {-# COMPLETE #-} machinery that we have
> today, I think we need to have a separate pragma for pattern synonyms
> that are intended to be transparent, non-abstract wrappers around
> patterns ({-# TRANSPARENT #-}, perhaps).
> 
> Ryan S.
> -----
> [1] https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/glasgow_exts.html#complete-pragma
> [2] https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs