I also realised the COMPLETE pragmas are even less helpful (at least
for my case mentioned above) as they cannot be used when orphaned.
For example, I tried to follow the partial solution of introducing
multiple COMPLETE pragmas, one per a concrete instance of
`HasSrcSpan`. I defined the pattern sy
I've just found this related ticket:
https://ghc.haskell.org/trac/ghc/ticket/14422
On 10/26/18 7:04 PM, Richard Eisenberg wrote:
Aha. So you're viewing complete sets as a type-directed property,
where we can take a type and look up what complete sets of patterns of
that type might be.
Then,
> On Oct 26, 2018, at 9:43 PM, Carter Schonwald
> wrote:
>
> ORDER of the abstracted constructors matters!
That's a very good point. So we don't have a set of sets -- we have a set of
lists (where normal constructors -- which have no overlap -- would appear in
the lists in every possible pe
off hand, once we're in in viewpattern/ pattern synonym land, ORDER of the
abstracted constructors matters!
consider
foo,bar,baz,quux,boom :: Nat -> String
plus some pattern synonyms i name "PowerOfTwo", "Even" and "Odd"
foo (PowerOfTwo x) = "power of two"
foo (Even x) = "even"
foo (Odd x) = "od
Aha. So you're viewing complete sets as a type-directed property, where we can
take a type and look up what complete sets of patterns of that type might be.
Then, when checking a pattern-match for completeness, we use the inferred type
of the pattern, access its complete sets, and if these match
Sorry I wasn't clear. I'm not an expert on the topic but it seems to me
that there are two orthogonal concerns:
1) How does the checker retrieve COMPLETE sets.
Currently it seems to "attach" them to data type constructors (e.g.
Maybe). If instead it retrieved them by matching types (e.g. "Mayb
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
{-# COMPLETE LL #-}
No types! (That's a rare thing for me to extol...)
I feel I must be missing something here.
Thanks,
Richard
> On Oct 25, 2018, at 12:24 PM, Sylv
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.
Currently we can specify the type *constructor* in a COMPLETE pragma:
pattern J :: a -> Maybe apattern J a = Just apattern N :: M
> [Ryan Scott:]
> In other words, this would work provided that you'd be willing to list
> every single instance of `HasSrcSpan` in its own COMPLETE set. It's
> tedious, but possible.
Yes, for the cases where `LL` is used monomorphically, we can use the
per-instance COMPLETE pragma, but it does no
You *can* put `LL` into a COMPLETE set, but under the stipulation that
you specify which type constructor it's monomorphized to. To quote the
wiki page on COMPLETE sets:
In the case where all the patterns are polymorphic, a user must
provide a type signature but we accept the definition regard
I think that `LL` is precisely intended for abstraction. If this
`COMPLETE` pragma were possible to implement then a user shouldn't
know the difference between the old and new representations.
The reason that `COMPLETE` pragmas are designed like this is that it's
how the pattern match checker is d
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
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 da
This sounds like an infelicity in COMPLETE pragmas. Do we have a documented
reason why fixing this is impossible?
Richard
> On Oct 25, 2018, at 7:36 AM, Shayan Najd wrote:
>
> Dear GHC hackers,
>
> On our work on the new front-end AST for GHC [0] based on TTG [1], we
> would like to use a pat
Dear GHC hackers,
On our work on the new front-end AST for GHC [0] based on TTG [1], we
would like to use a pattern synonym like the following [2]:
{{{
pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a
pattern LL s m <- (decomposeSrcSpan -> (m , s))
where
LL s m = compose
15 matches
Mail list logo
