Haskell naming conventions

[Sean L. Palmer]

It occurs to me that Haskell would be quite a bit easier for OO and traditional programmers to grasp if Haskell would actually use the correct, or at least more commonly used, names for things.

For instance, 

data Maybe a = Nothing | Just a

Maybe is a type constructor and Nothing and Just are data constructors.

So it makes me wonder why the use of the data keyword... wouldn't it make more sense to say: 

type Maybe a = Nothing | Just a

?  Either that or perhaps change the descriptions "type constructor" and "data constructor" to something that fits with the keywords used.  

Likewise with class, type class, and instance:

class Eq a where
        (==) :: a -> a -> Bool

That actually declares a type class, not a class.  So why the use of the keyword class?  Is it done merely to confuse C++ and Java programmers?  The concept of type class in Haskell apparently roughly corresponds to the concept of "interface" in Java.  So why not call it interface?  

Instance is also confusing:

instance Eq Integer where 
  a == b = a `integerEq` b

That actually declares that Integer is a type, not an "instance" in the traditional use of the word.  A C++ programmer would probably use the word "subclass" instead of "instance".

Then consider how different a meaning "return" has in Haskell than it does in C.   ;)

Does anyone else think this is a problem?  If so, is it fixable?

I guess from reading the many tutorials and FAQ's, that I'm in the same boat as everybody else.  I consider myself a pretty bright boy, I've learned all kinds of other programming languages, from asm to forth to basic, pascal, C, C++, java, and C#...  but this Haskell business, has me almost stumped.  I mean, I understand the basic ideas pretty easily enough, but there seems to be such syntactical wierdness that to understand how to program in Haskell above the level of toy programs requires one to revisit every single design decision that went into making the language and its libraries, and grasp everything along the way, not only its function but also its peculiar nomenclature, and usually two different ways to say the same thing (maybe more).  Only after following this long tortuous path will one ever be able to actually write useful programs.  

If Haskell (or any language of this style) is ever to gain a larger following, it would probably be wise to accomodate the existing programmer knowledge base a little more.  I believe that the same core language, with cleaner design, different keywords, maybe different operators, would probably be readily accepted.  

There are many things that contribute to making Haskell less approachable, the above is just one.

I wonder if there are any tutorials out there that provide a 1:1 mapping of concepts and idioms from other common languages into Haskell; small snippets of examples of pure translations would make things easier to grasp for some people than any amount of longwinded explanation.  Probably there are easier ways to do the same things in Haskell, but it would be useful for beginners to get a unedited translation, even if that means heavy use of do-notation.  At least people could then start writing imperative style Haskell programs immediately, and yeah that's not good style, but you can't learn good style if you can't accomplish anything and are stuck at square one.

Frustratedly,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://haskell.org/pipermail/haskell/attachments/20031223/3c60595e/attachment.htm