Opened 18 months ago

Last modified 18 months ago

#12006 new bug

Can't infer constraint of pattern synonyms

Reported by: Iceland_jack Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.1
Keywords: PatternSynonyms Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Can't infer constraint of:

-- pattern Real' :: Num a => a -> Complex a
pattern Real' r <- r :+ _
  where Real' r =  r :+ 0
teR4.hs:12:25: error: …
    • No instance for (Num t) arising from the literal ‘0’
      Possible fix:                        
        add (Num t) to the context of
          the type signature for:    
            Main.$bReal' :: t -> Complex t
    • In the second argument of ‘(:+)’, namely ‘0’
      In the expression: r :+ 0
      In an equation for ‘$bReal'’: $bReal' r = r :+ 0
Compilation failed.

Should it be able to?

Change History (3)

comment:1 Changed 18 months ago by mpickering

Keywords: PatternSynonyms added; TypeSynonyms removed

The problem here is that the type signature of the builder is fixed by the type of the matcher. By fixed, I mean literally fixed, we first typecheck the matcher with either the signature or infer the type and then we create an Id for the builder with precisely the same type.

So the problem here is that the inferred type for the matcher doesn't require the Num constraint and so the builder type is t -> Complex t rather than Num t => t -> Complex t as you desire.

From what I could work out from reading the source, the way it is like this is for mainly because of implementation problems. There is some more confused discussion on this ticket - - it is something I hope to look at again one day.

Thank you for all these reports, they are very useful, I am interested in any pattern synonyms tickets so feel free to add me to cc to make sure that I see them.

comment:2 Changed 18 months ago by Iceland_jack

Sure thing, I was starting to worry I was spamming with tickets :)

comment:3 Changed 18 months ago by simonpj

Yes, I think in principle it should be possible to infer a type that works for both builder and matcher. I'm not quite sure how hard that would be; probably not terrible.

Of course you can always work around the difficulty by providing a signature.

Note: See TracTickets for help on using tickets.