> > These suffixes are doing namespace management, avoiding name clashes
> > between different things that you want to call empty. But Haskell
> > already has a perfectly good language mechanism for doing this --
> > the module system! Why is emptyX preferable to X.empty? The latter
> > convention is much more flexible.
>
> I prefer recognizing common interfaces and making appropriate classes.
> It is more convenient and more flexible than qualified imports:
>
> [...reasons deleted...]
But classes and qualified imports are not in competition! Suppose you
have two *classes* that both need/want the same name. For example,
you may have a class of sequences and a class of finite maps that
both want to use an empty method. Do you call one emptyS and the
other emptyFM? Or do you disambiguate using qualified names?
You might say, "Neither! Make a common superclass containing empty
and anything else common to both sequences and finite maps." Unfortunately,
this doesn't work because type constructors for sequences and finite maps
both have different kinds and different constraints on their elements.
> I don't like modules that have to be imported qualified.
Can you be more specific? I understand that you don't want to use
qualified names in those situations where a class would be a better
solution, but what about when classes alone don't solve the problem?
Chris
