> Yes, I agree with your [Possibly not...] statement, which I
> why I think
> I'm in favor of having the "two Preludes" option, but having
> both standard
> (this is part of my reason for not adopting Ashley's Prelude).
>
> I think a reasonable way to do it would be to have
>
> module AdvancedPrelude
>
> which defines the map, fold, etc functions all in their own class,
> something like:
>
> class Map m a where
> map :: (a -> b) -> m a -> m b
> mapAccum :: ...
>
> and so on. It also defines things like Group, Ring, etc.
There's no problem with having an AdvancedPrelude, but I would argue
against building the standard Prelude on top of it for purely practical
reasons - people like me who have to maintain the code and don't
understand Groups and Rings would be disadvantaged. It would also be
hard, I'm guessing, to prevent the advanced prelude from leaking into
error messages even if you hide every scrap of it from the Prelude's
interface. Moreover, the vast majority of Haskell programmers don't
need the AdvancedPrelude, yet they'd be linking in most of it whenever
they write a program.
Just have a separate package containing AdvancedPrelude, and use
-fno-implicit-prelude with GHC.
Cheers,
Simon
