#10653: PatternSynonyms should be imported/exported as part of the wildcard notation -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: pattern | synonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): gridaphobe's interpretation of my proposal is more accurate. I do mean to allow the reassociation of pattern synonyms in any module. This means that you have to "chase the import chain" to figure out what `T(..)` means. But this is ''already'' true! {{{ module A ( T(MkT1,MkT2) ) where data T = MkT1 | MkT2 | MkT3 module B ( T(..) ) where import A ( T(MkT1) ) module C ( T(..) ) where import B ( T(..) ) module D where import C ( T(..) ) }}} Figuring out what is in scope in `D` requires chasing a module chain. My proposal makes this no different. Indeed, I believe (if we drop the redundant `pattern` keyword in the parenthesized list after a datatype) my proposal makes it so that data constructors are no longer privileged at all. For example: {{{ module E ( T( Pat ), pattern Mk ) where data T = Mk pattern Pat = Mk }}} This means that `Pat` is imported with `T(..)` but `Mk` has to be imported separately. Is this confusing? Perhaps. But perhaps it is also sensible if done for backward compatibility. I'm not really against putting all of this in the datatype declaration instead of in an export list. (Actually, I quite like `data T = PublicMk | abstract PrivateMk` or similar.) But aiming to avoid module chasing to understand `T(..)` is a red herring. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10653#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler