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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
