I've taken a look at these. I'll limit myself to just one comment:
>1.1.1. Constructor names
>
> Empty values of type X have the name emptyX, e.g. emptySet.
You've struck a pet peeve of mine. 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. It allows the
user to
- use the full module name, which could be long and descriptive
import qualified SplayTreeSet
... SplayTreeSet.empty ...
- use a short module name, when that is more convenient
import qualified SplayTreeSet as S
... S.empty ...
- do away with the prefix altogether, when appropriate
import SplayTreeSet
... empty ...
Under the suffix scheme, you not only lose any such flexibility, you
also have a major problem deciding on the right name. For example,
you've listed emptySet, but what if you have two or more different
implementations of sets? Should they be called emptySplayTreeSet
and emptyTrieSet? Or do you use emptySet for both, and disambiguate
using the module system (SplayTreeSet.emptySet)?
Also, I've noticed a tendency to shorten the suffixes as much as
possible (eg, emptyS or emptyFM), in which case you again quickly
run into name clashes.
If anybody has a good argument against using the module system in
this context, I would very much like to hear it, because I use the
module-based convention almost exclusively in Edison.
Chris
