... | @@ -25,7 +25,7 @@ However, there are many good reasons to do both the AMP and FTP generalizations |
... | @@ -25,7 +25,7 @@ However, there are many good reasons to do both the AMP and FTP generalizations |
|
|
|
|
|
- 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.
|
|
- 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.
|
|
|
|
|
|
- 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. We're better as a community at "getting ahead" and making changes early in a GHC release cycle. Far more code is "GHC 7.10 ready" at this point in the release cycle than was at a comparable point in the GHC 7.8 cycle, which exacerbates this problem.
|
|
- 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](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. We're better as a community at "getting ahead" and making changes early in a GHC release cycle. Far more code is "GHC 7.10 ready" at this point in the release cycle than was at a comparable point in the GHC 7.8 cycle, which exacerbates this problem.
|
|
|
|
|
|
- Stretching out these sorts of changes over many releases increases the complexity of CPP and other tricks that authors have to use to maintain their packages over long support windows, so there is a case to be made for a fairly "sharp shock" to get this out of the way at the same time as the `Applicative`-`Monad` Proposal. Results so far have shown that the AMP changes break far more code than generalizing these signatures.
|
|
- Stretching out these sorts of changes over many releases increases the complexity of CPP and other tricks that authors have to use to maintain their packages over long support windows, so there is a case to be made for a fairly "sharp shock" to get this out of the way at the same time as the `Applicative`-`Monad` Proposal. Results so far have shown that the AMP changes break far more code than generalizing these signatures.
|
|
|
|
|
... | | ... | |