[Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Anton van Straaten]

John Goerzen wrote:
> Though if all we're talking about is naming, I would still maintain that
> newbie-friendly naming is a win.  We can always say "HEY MATHEMETICIANS:
> APPENDABLE MEANS MONOID" in the haddock docs ;-)

This is backwards.

The real problem here is that most people coming from other languages 
aren't used to working with structures as abstract as monoids, and a 
natural first instinct is to try to un-abstract them, in this case via 
the suggested renaming.  The thought process tends to be something like 
"I didn't have this problem in language X, Haskell must be doing 
something wrong."

This instinct is not appropriate in the Haskell context.  (Although as 
others have noted, the documentation doesn't do much to help guide 
people through this.)

One of the most mind-bogglingly important features of Haskell is that it 
  is actually possible to make effective use of structures such as 
monoids in real code.  In most languages, you wouldn't even try this.

But if you're going to create a zoo of abstract structures like monoids, 
with the aim of being able to use them as very general building blocks, 
the last thing you should be doing is naming them according to 
particular applications they have.  This goes against the goal of 
abstracting in the first place, and will ultimately be confusing and 
misleading.  (As I pointed out in another comment, the 
misleadingly-named 'mappend' is an example of this.)

If there's an existing name for the exact structure in question, it 
makes sense to use that name.  If you're unfamiliar with the structure, 
then you're going to need to learn a name for it anyway - why not learn 
a name by which it is already known in other contexts?

The main counter to the latter question is "I want to give it a new name 
in order to connote an intended use," but unless the connotation in 
question is as general as the structure being named, this is a mistake.

This issue is not unique to structures from abstract algebra & category 
theory.  It can arise any time you have a very polymorphic function, for 
example.  It can often make sense to provide a more specifically named 
and typed alias for a very general function, to make its use more 
natural and/or constrained in a particular context, e.g.:

   specificName :: SpecificType1 -> SpecificType2
   specificName = moreGeneralFunction

Similarly, in the case of monoid, we need to be able to do this, at 
least conceptually:

   Appendable = Monoid

...possibly with some additional constraints.  In other words, "HEY 
PROGRAMMERS: YOU CAN USE MONOID AS AN APPENDABLE THINGY (AMONG OTHER 
THINGS)".

This is perhaps an argument for a class alias mechanism, such as the one 
described at: http://repetae.net/recent/out/classalias.html

But in the absence of such a mechanism, we shouldn't succumb to the 
temptation to confuse abstractions with their applications.

> Much as I dislike Java's penchant for 200-character names for things,
> I'm not sure Monoid is more descriptive than
> SomeSortOfGenericThingThatYouCanAppendStuffToClassTemplateAbstractInterfaceThingy
> :-)

Usable descriptive names for very abstract structures are just not 
possible in general, except by agreeing on names, which can ultimately 
come to seem descriptive.  For example, there's nothing fundamentally 
descriptive about the word "append".

Anton