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.sc...@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@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
