* In the defining module of a data type (''and nowhere else'') you can
#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 gridaphobe): Replying to [comment:10 simonpj]: list pattern synonyms in the export list thus `T( ..., pattern A1 )`, and that permanently associates `A1` with `T`. Hmm, I understood Richard's proposal to mean that ''any'' module can associate pattern synonyms with a data type in the export list. In this case the association would not be permanent, as client modules could always choose to break the association or associate different pattern synonyms, by changing their export list. So in my interpretation you would have to to chase the import chain to figure out precisely what `T(..)` means, and there would be no "maximal" meaning. I can see the argument against that. If we go with your interpretation and say that ''only'' the defining module can associate pattern synonyms with a data type, I agree that it would be better to declare the association alongside the data type. I guess the real question is this: do we want to allow modules to associate pattern synonyms with data types that they have imported from somewhere else? I can see one situation where this would be handy. Suppose a package `p` changes one of its core data types, but does not export pattern synonyms to provide backwards compatibility. A client could write a new package `p-compat` that provides the necessary patterns and associates them with `p`s data types, thus seamlessly recreating the old API. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10653#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler