Re: [GHC] #13778: explicitly bidirectional patterns should not report Recursive definition" when used in view pattern expression position

5 Jun 2017

      #13778: explicitly bidirectional patterns should not report Recursive definition"
when used in view pattern expression position
-------------------------------------+-------------------------------------
        Reporter:  heisenbug         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
                                     |  PatternSynonyms
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Harump.  I think you want

 1. To infer the type of `One` from its "builder"
 {{{
   One = 1
 }}}

 2. To use that type when inferring the type of the pattern

 But actually GHC does it the other way round

 1.  Infer the type of the pattern
 2.  Use that in checking the type of the "builder"

 There's a good reason for this.  Here's a Note from `RnBinds`:
 {{{
 Note [Pattern synonym builders don't yield dependencies]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 When renaming a pattern synonym that has an explicit builder,
 references in the builder definition should not be used when
 calculating dependencies. For example, consider the following pattern
 synonym definition:

 pattern P x <- C1 x where
   P x = f (C1 x)

 f (P x) = C2 x

 In this case, 'P' needs to be typechecked in two passes:

 1. Typecheck the pattern definition of 'P', which fully determines the
    type of 'P'. This step doesn't require knowing anything about 'f',
    since the builder definition is not looked at.

 2. Typecheck the builder definition, which needs the typechecked
    definition of 'f' to be in scope; done by calls oo tcPatSynBuilderBind
    in TcBinds.tcValBinds.

 This behaviour is implemented in 'tcValBinds', but it crucially
 depends on 'P' not being put in a recursive group with 'f' (which
 would make it look like a recursive pattern synonym a la 'pattern P =
 P' which is unsound and rejected).
 }}}
 So I don't see an easy way to give you want you want.

 The only think I can think of is to allow some kind of monomorphic
 recursion.   But it's easy to program around, so I'm disinclined to
 fiddle.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13778#comment:2
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler