Wolfgang Jeltsch
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