I *knew* people couldn't resist talking about names! :-) OK, I've
invited you to do this, but more than a dozen mails solely about the
first item of section 1.1.1 were a little bit surprising...
To be more serious: Perhaps I wasn't clear enough about the purpose of
these conventions. What they're trying to describe is current practice
in hslibs, not what would be the best thing if they were rewritten
from scratch. Note that hslibs currently contains about 100 modules,
and there are probably lots of programs out there using this library
collection. Making fundamental changes like the replacement of
suffixes by qualification would break almost every single program
using hslibs. I doubt that a lot of people would cheerfully change
most of their programs they've written, not to mention the heart
attack SPJ would probably suffer... ;-) I remember the tons of mails
on the developer lists about an extremely simple change (to the
inaugurated: makeForeignObj).
Personally, I'm not a true believer in this whole prefixing/suffixing
business either. I've silently dropped the rl_ prefix from the names
in the Readline lib, nuked the gl/glu/glut prefix in my HOpenGL
binding, etc. But these were either seldom used or completely new
libs, you can't do this for hslibs in general. If we were living in a
better world, Haskell would have a more expressive module system
(i.e. parameterized, first class modules in non-flat name-space, etc.)
and people would have used it correctly from the start. But alas, we
have to live with the current state of things, at least for H98. For
Haskell 2 there should probably be a hslibs 2, too, incorporating what
we've learned from the design of the H98 libs.
To be more concrete: Although Set.empty vs. emptySet or IORef.update
vs. updateIORef seem to have some advantages, but things are not always
that simple: What about e.g. the xToY convention? Or getEnv? (The
environment is not a separate type, much less an own module.) And what
about Integer.to? (Even if there was a module Integer, I'd prefer
toInteger.) It seems that we have to live with prefixes/suffixes in
one way or the other.
And note that even in their current (probably non-perfect) form the
conventions are of some use: They state clearly that e.g. readIORef is
the correct name (not getIORef), updateIORef returns (), stToIO is a
misnomer (should be sTToIO), makeStablePtr should better be named
newStablePtr, etc. Making a careful transition to a consistent scheme
within hslibs is likely to be non-trivial amount of work.
What I was hoping to get were some less drastic improvements of the
conventions, e.g. proposals for the names of non-monadic versions of
updateBlah, some guidelines when a type should live in its own module,
etc.
Cheers,
Sven
