Haskell naming conventions

[Frank Atanassow]

On Dec 24, 2003, at 2:29 AM, Sean L. Palmer wrote:

> 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.

I don't think changing a few keywords will have any significant impact; 
the differences between Haskell and Java run much, much deeper.

> 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

No, it wouldn't. There is a difference between a `type' and a 
`datatype': a datatype is a special kind of type which comes equipped 
with a set of functions---the data constructors---which interact nicely 
with pattern-matching so that one can determine exhaustiveness and 
non-ambiguity of matches. Types in general, for example the Double 
type, do not satisfy these conditions.

> Likewise with class, type class, and instance:
>  
> class Eq a where
>         (==) :: a -> a -> Bool
>  
> That actually declares a type class, not a class.

According to the normal rules of English, every `type class' is 
necessarily a `class', isn't it?

> So why the use of the keyword class?  Is it done merely to confuse C++ 
> and Java programmers?

Yikes! The secret is out! ;)

> The concept of type class in Haskell apparently roughly corresponds to 
> the concept of "interface" in Java.  So why not call it interface? 

Haskell type classes are older than Java. Perhaps you should petition 
Sun instead?
 
> 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.

No, that Integer is a type is a necessary precondition of this instance 
declaration. The declaration rather says that Integer belongs to the 
type class Eq.

The choice of the syntax `instance' here probably arises from the idea 
that a type class is relation (predicate) on types; many people say 
that, for example, (x,y) `is an instance of' the relation R if x R y.

> A C++ programmer would probably use the word "subclass" instead of 
> "instance".

Not really. Up above you already compared type classes to Java 
interfaces. It follows that a Haskell instance T of class C rather 
corresponds to a Java class T which implements an interface C.

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

"return" was probably chosen precisely because of what it suggests by 
analogy with C's return. Of course there are big differences, but can 
you think of a better name?

> Does anyone else think this is a problem?

I think any difficulties stemming from Haskell's choice of keywords are 
dwarfed by the differences stemming from Haskell's semantics.

> If so, is it fixable?

Haskell is much too old to be changing its surface syntax. Of course, 
you can always change GHC's input grammar, fork it, call it Haskell++ 
and see if anybody will use it. :) Or use Template Haskell.

>  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.

The standard response is:

"It is practically impossible to teach good programming to students 
that have had a prior exposure to BASIC: as potential programmers they 
are mentally mutilated beyond hope of regeneration." -- Edsger 
Dijkstra, How do we tell truths that might hurt?

http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html

> 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. 

IMO, there really isn't much `syntactical weirdness' in Haskell; it has 
a pretty accessible syntax and first-time programming students appear 
to exhibit largely the same problems with Haskell syntax as they would 
in other languages (forgotten parentheses, etc.). What you are really 
complaining about is Haskell's semantics, but you don't realize it yet.

> 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. 

I believe you are very mistaken on that count. Is Howard Dean sure to 
win the American election if he starts speaking with a Texas accent?

Anyway, most of us believe Haskell already has a cleaner design than 
other languages.
 
> 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.

I don't know of any, but you can look here:

http://www.haskell.org/bookshelf/

> 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.

What is it you want to accomplish? If you post specific questions, 
maybe people can help you.

I think the approach you outline is not really a good one. Though I 
think it is helpful to point out analogies between language concepts, 
Haskell will indeed be frustrating to use if you write your programs by 
translation, so to speak, and people tend to develop both good and bad 
habits early.

The Haskell paradigm is indeed quite different from the C/C++/Java 
paradigm, so you might have to relearn quite a bit before you can start 
integrating concepts and techniques you've already acquired. But if 
Haskell were just another clone of C, what would be the point of 
learning it? You might as well use Java.

The point of learning Haskell should not be merely to learn how to 
re-express what you already know in a different syntax; it should be to 
learn genuinely new things, and to get a fundamentally different 
perspective on computing---the pure functional paradigm.

Regards,
Frank