3 ms·
> If we’re careful in our module exports, a change like this can be done in a backward-compatible way. Such an approach is outlined here (http://www.yesodweb.co
by sparkie 13y ago
> If we’re careful in our module exports, a change like this can be done in a backward-compatible way. Such an approach is outlined here (http://www.yesodweb.com/blog/2011/10/settings-types http://www.yesodweb.com/blog/2011/10/settings-types).
The problem with this import solution is that almost nobody actually does it! Nearly every module you will ever import exposes most of the constructors of the ADTs they define - because Haskell encourages it - it's much simpler and cleaner to pattern match over constructors than the functions you use in place of them in order to encapsulate the constructors - which you need to use guards to match over instead.
- mkehrt 13y agoHaskell's module system is kind of weak. Something like an ML variants, with interfaces being defined separately from implementations, is much nicer.
- andolanra 13y agoYou could also pattern-match over them with View Patterns[^1], i.e. export an alternate ADT that is the 'acceptable' view on the data and a function that takes the encapsulated implementation and turns it to the alternate representation—but I have literally never seen this done, save in the documents describing the motivations for View Patterns. [^1]: https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns
- ibotty 13y agoin addition to what andolanra said about view patterns there are also pattern synonyms in recent ghc, which makes this feasible.