The patch to export liftA2 from Prelude has just landed in GHC.
This means that you can expect the change to come to you with the next major GHC release (likely 9.6).
This is a breaking change - please see the migration guide if you think it might affect you.
This change is motivated by a few things:
liftA2 is an often used function, even more so than (<*>) for some
people.
When implementing Applicative, the compiler will prompt you for either
an implementation of (<*>), or of liftA2, but trying to use the latter
ends with an error, without further imports. This could be confusing
for newbies.
For teaching, it is often times easier to introduce liftA2 first,
as it is a natural generalisation of fmap.
This change seems to have been unanimously and enthusiastically
accepted by the CLC members, possibly indicating a lot of love for it.
…before everyone else nominates their favourite “non-lazy” entities to be added to the Prelude (at least the ones which aren’t type-class methods): would having them together in auxiliary Strict submodules e.g. Data.Foldable.Strict containing foldl', foldMap', etc be a more viable alternative - perhaps even a Prelude.Strict module?
What is the aim in adding them to a Data.Foldable.Strict? They’re already exported from e.g. Data.Foldable. I think the goal with adding them to Prelude is to have them available with no extra steps (i.e. to reduce how much you have to go out of your way to do “the right thing”).
…17 methods isn’t a “big surprise” - it’s a big disappointment. The only two essential methods are foldr and foldMap - the other 15 can just be free-standing overloaded definitions.
But if this style of agglomeration is considered “best practice” these days…can:
unit :: {...} => a -> m a
map :: {...} => (a -> b) -> (m a -> m b)
join :: {...} => m (m a) -> m a
now be added to the Monad class - I suspect the categorists amongst us would find the current situation annoying, too (oh, and Eq could have back (/=) too, since that change has apparently caused some pedagogical problems…).
Personally I take the large number of methods as an indicator that Foldable is a pretty poor abstraction that doesn’t really capture anything precisely.