> Personally I'm not all that keen on effectively developing a custom
> Prelude, but I can live with it if you're strongly in favour.
There are certainly pros and cons. I am not /strongly/ in favour of a custom
Prelude that exports a lot more names than the standard one (though there are
some good arguments, see below). However, we already do have Darcs.Prelude and
making use of it in situations like this (i.e. to ease the * -> Type
migration) is not really a policy change; so I /am/ strongly in favour of
exporting 'Type' from Darcs.Prelude.
Regarding a more general custom Prelude, it would solve two issues for me:
first, having to add trivial imports, as well as having to remove them if they
are no longer used (because of warnings), is a constant annoyance; second,
these trivial imports lead to unnecessary conflicts with unpublished work, of
which I tend to have quite a lot. So I wouldn't mind to have much of
Data.List, Data.Maybe, Control.Monad+Applicative, and probably some more
available from Darcs.Prelude. We may have to occasionally hide some names
there if new additions cause trouble (or add other kinds of work-arounds), but
that's a lot less maintenance work than what we have now, and it's
concentrated in one module instead of being spread all over the place.
What are the disadvantages in your view?
|