Wolfgang Jeltsch <[EMAIL PROTECTED]> 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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
