[GHC] #10653: PatternSynonyms should be imported/exported as part of the wildcard notation

17 Jul 2015

      #10653: PatternSynonyms should be imported/exported as part of the wildcard
notation
-------------------------------------+-------------------------------------
              Reporter:  gridaphobe  |             Owner:
                  Type:  feature     |            Status:  new
  request                            |         Milestone:  7.12.1
              Priority:  normal      |           Version:  7.11
             Component:  Compiler    |  Operating System:  Unknown/Multiple
              Keywords:  pattern     |   Type of failure:  None/Unknown
  synonyms                           |        Blocked By:
          Architecture:              |   Related Tickets:
  Unknown/Multiple                   |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
 Suppose I have the following two modules.

 {{{#!hs
 {-# LANGUAGE PatternSynonyms #-}
 module A where

 data A = A2 Int Int

 pattern A1 a <- A2 a _ where
   A1 a = A2 a 0
 }}}
 {{{#!hs
 module B where

 import A ( A(..) )

 a = A1 0
 }}}

 When I try to compile `B.hs` I get an error because `A1` is unbound in
 module `B`.

 {{{
 $ ghc --make B.hs
 [1 of 2] Compiling A                ( A.hs, A.o )
 [2 of 2] Compiling B                ( B.hs, B.o )

 B.hs:5:5:
     Not in scope: data constructor ‘A1’
     Perhaps you meant ‘A2’ (imported from A)
 }}}

 The issue is that the import `A(..)` brings all of `A`s data constructors
 and accessors into scope, but not any associated pattern synonyms. Instead
 I have to enable `PatternSynonyms` in module `B` (or just import
 everything from `A`).

 {{{#!hs
 {-# LANGUAGE PatternSynonyms #-}
 module B where

 import A ( A(..), pattern A1 )

 a = A1 0
 }}}

 I'd like to propose that we extend the semantics of the `A(..)`
 import/export notation to include any associated pattern synonyms. I think
 this is in line with the spirit of `PatternSynonyms`, that the extension
 should allow internal refactoring without causing API breakage, and that
 the extension should only need to be enabled to *define* pattern synonyms.

 FYI, this issue does appear in the wild, I ran into it while working on
 https://phabricator.haskell.org/D861 and had to modify two import lists in
 Cabal.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10653
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

tags

participants (1)