On Sun, Feb 1, 2015 at 4:09 AM, Herbert Valerio Riedel <hvr@gnu.org> wrote:

Fwiw, the 3+ year argument applies to almost any `base`-augmentation if
you need such backward-compatibility. By that argument there's little
incentive to add anything to `base` at all.

That isn't true. Careful additions of things to existing modules that are generally imported qualified are fine.

Additions of new modules are fine. Yes, a side effect of being 'base' is that it is harder to change and must consider backward and forward compatibility over a longer time span.

So pre-FTP (in GHC 7.8), the following is needed to more or less emulate
the post-FTP state:

[many line of ugly imports]

That isn't the right tradeoff. Without FTP, one imports qualified:

import qualified Data.Foldable as F

import qualified Data.Traversable as T

If importing qualified is too much a barrier to use of Foldable and Traversable - then I think we should re-consider how useful they are.

If we
don't intend to make Foldable/Traversable a first-class citizen of
Haskell to help increase its adoption, why have it in `base` in the
first place?

"first-class citizen" better not equate to "you get it with the Prelude" nor "you can always import it unqualified". If we use either of those as the bar, then we will end up with huge number of things in default scope, and we'll namespace it by prefix strings alá PHP.

Moreover, how do we justify (other than by historic accident) that the
more generalised synonyms are stored away in modules … Do lists really require such a special
privilege?

Yup, historic accident and lists do get special privilege. We could easily turn your question around: Why do Foldable and Traversable deserve to be not only importable unqualified, but by all programs as part of the Prelude?

Why not rather place the more general versions into the default scope … This results in a more symmetric
situation.

It might be more symmetric. But I don't see universal acclaim that Foldable and Traversable are a generalization to be preferred over lists in the majority of code. And the "why not" is because it is a big change to the Prelude with negative consequences judged significant by many of us.

The design-choices of the FTP implementation were motivated to achieve
its goal while breaking as little existing code as possible. We assumed
this to be the better compromise rather than introducing a severe
breakage of the majority existing Haskell code which don't
qualify-import `Data.List`.

In the evaluation, we need to consider at least a third choice: Not to do FTP at all.

- Mark