... | ... | @@ -19,11 +19,15 @@ However, there are many good reasons to do both the AMP and FTP generalizations |
|
|
|
|
|
- Despite this broad explanatory power and the ability to derive connections between a large chunk of the combinators that came before these abstractions were even named, they remain relegated to modules off to the side that contain combinators that are harder to use for the simple reason that using them requires qualified imports or massive amounts of manual hiding.
|
|
|
|
|
|
- Once we make `Applicative` a superclass of `Monad`, `mapM` is basically \*never\* the right combinator for, well, anything. It requires too tight a constraint (`Monad` rather than `Applicative`) on one hand. Going the 'wrong' direction and adding a monomorphized `traverse` breaks far more code, and makes the scoping problems even worse.
|
|
|
- Nothing in `Foldable` or `Traversable` ever changes the "shape" of the container it is given. This is actually more information for the user than seeing a combinator accepts any list and returns any list. While we give up the knowledge that the thing we're walking over is a list, we gain information as well. The more general signatures can often tell the user more about what a combinator can do behind the scenes. e.g. we can know that `forM` will not change the number of elements in the container by leaning on the `Traversable` laws alone and the lack of any other way to construct the result value. We're not just able to rely the fact that it gives back a list, but we can rely on the specific shape of the structure we get back.
|
|
|
|
|
|
- At the time of the "Burning Bridges Proposal" thread on the libraries mailing list back in 2013, this question was widely polled, and there was an overwhelmingly strong call from the community for generalization. Admittedly, this was from the self-selecting subset of the community that is active on the [ libraries@ mailing list](https://www.haskell.org/mailman/listinfo/libraries).
|
|
|
|
|
|
- One thing that we were very careful to avoid during this entire wave of generalization is an impact to performance on either asymptotic or constant factor grounds. The continuous performance testing that is done on GHC has done a lot to keep us honest in this regard, but has definitely complicated development.
|
|
|
|
|
|
- Nothing in `Foldable` or `Traversable` ever changes the "shape" of the container it is given. This is actually more information for the user than seeing a combinator accepts any list and returns any list. While we give up the knowledge that the thing we're walking over is a list, we gain information as well. The more general signatures can often tell the user more about what a combinator can do behind the scenes. e.g. we can know that `forM` will not change the number of elements in the container by leaning on the `Traversable` laws alone and the lack of any other way to construct the result value. We're not just able to rely the fact that it gives back a list, but we can rely on the specific shape of the structure we get back.
|
|
|
- For better or worse, several hundred packages have already been adapted be compatible with GHC 7.10RC2 expecting that it would be a reasonable approximation of the final, shipping version of GHC 7.10. Package authors who have been actively working and who have attempted to build completely without warnings will have changes to partially undo. Keep in mind that they need to keep the AMP changes, and just roll back the FTP related ones, if the \[Prelude710/List\] plan was followed. Rolling these changes back would mean that we're going to ask our most proactive users to re-release the majority of these packages, and to use the ability to change .cabal files for historic versions to make their old versions uninstallable or risk them being selected by cabal in the build plan. That is a messy solution at best.
|
|
|
|
|
|
- Finally, once we make `Applicative` a superclass of `Monad`, `mapM` is basically \*never\* the right combinator for, well, anything. It requires too tight a constraint (`Monad` rather than `Applicative`) on one hand. Going the 'wrong' direction and adding a monomorphized `traverse` breaks far more code, and makes the scoping problems even worse.
|
|
|
|
|
|
## FAQ
|
|
|
|
... | ... | |