But I do think my proposal answers Simon's first point: the programmer says explicitly what should be included by any import of a datatype. This choice is checked in my proposal, but I don't imagine that would be a challenge to implement. The interface file would indicate what pattern synonyms are included with a datatype. It all doesn't seem very complicated.
As for smart constructors: I think that pattern synonyms subsume
#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:8 goldfire]: traditional "smart constructors". They should really be pattern synonyms now! With the change proposed in this ticket, clients might not even know the difference between a real constructor and a smart one.
Here might be a motivation and a design principle for this feature: a
library should be able to refactor a concrete data type without affecting client code. This refactoring would require exporting pattern synonyms mimicking the old behavior. But it's conceivable a client would never know. I agree on all accounts. We should strive to enable client code to be oblivious to library refactorings. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10653#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler