Export lists in modules
ketil+haskell at ii.uib.no
Thu Feb 23 02:20:18 EST 2006
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
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.
¹ 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
More information about the Haskell-prime