Export lists in modules

[Ketil Malde]

Wolfgang Jeltsch <wolfgang at jeltsch.net> writes:

>> Personally, I would greatly prefer to have libraries that do not clash
>> with common Prelude functions.

> I would solve this problem by reducing the Prelude to just a core.  List 
> function could go, for example, (mostly) into Data.List.

If this means that you must import Data.List almost everywhere, this
won't change anything - only add yet another import to every file.

I know most - if not all - of my modules use lists, but just in case,
I checked with the darcs sources - 95 of 107 source files appear to
use lists. Ignoring the : and ++ operators (looking for null, map, and
filter) the count is 76 files.

>> If you always have to qualify it, what's the advantage of
>> Data.Set.empty over emptySet again?  At least with 'emptySet' I know
>> what to grep for.

> I would import Data.Set as Set.  So I would use Set.empty instead of
> emptySet.   

The problem is that I might import Data.Set as S.  Joe would import it
as something else, and Frank would use yet another prefix.

> The advantage is that Set.empty is more structured.  

I'm not sure why that is such an advantage.  To me, structure sounds
like a means rather than an end.  If it made things simpler, I'd be all
for it, but IMO it doesn't - and it makes some things more difficult. 

> You can easily distinguish the kind of operation (empty) and the
> type you are working with (Set).

Only by convention - i.e. I must manually rename the module in a way
that is meaningful with respect to the type.

(As an aside, 'empty' is a rather poor example, as it is not a Prelude
function.  Take 'null' or 'map' or - why not - '(:)' instead)

Don't get me wrong, I don't want to go back to the old ways of
prefixing *every* identifier with a module abbreviation.  But I resent
having to add a multi-line half-standardized set of imports to over
90% of my source files.

In short, I'm fairly comfortable with the scope of the Prelude¹ 
and I don't mind modules like e.g. Data.Map and Data.Set, which are
similar in many ways to recycle some of their identifiers.  However, I
think minimizing the number of name clashes should be a goal, and
modules that are intended to be used together, should try to avoid
using the same identifiers.  And this implies that Prelude identifiers
should *not* be recycled, unless you intend to replace the Prelude.

-k

¹ I might want to shove some of the association list stuff into
Data.List, but certainly not all list functionality.
-- 
If I haven't seen further, it is by standing in the footprints of giants