<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1264" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>For instance, </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>data Maybe a = Nothing | Just
a<BR></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face="Courier New">Maybe</FONT> is a type
constructor and <FONT face="Courier New">Nothing</FONT> and <FONT
face="Courier New">Just</FONT> are data constructors.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>So it makes me wonder why the use of the <FONT
face="Courier New">data </FONT><FONT face=Arial>keyword... wouldn't it make
more sense to say: </FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>type Maybe a = Nothing | Just
a</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>? Either that or perhaps change the
descriptions "type constructor" and "data constructor" to something that fits
with the keywords used. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Likewise with <FONT
face="Courier New">class</FONT><FONT face=Arial>, type class, and <FONT
face="Courier New">instance</FONT>:</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>class Eq a where</FONT></DIV>
<DIV><FONT face=Arial size=2> (==) :: a
-> a -> Bool</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>That actually declares a <EM>type class</EM>, not a
class. So why the use of the keyword <FONT
face="Courier New">class</FONT><FONT face=Arial>? 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? </FONT></FONT></DIV>
<DIV><FONT face=Arial size=2><FONT face=Arial></FONT></FONT> </DIV>
<DIV><FONT face=Arial size=2><FONT face=Arial>Instance is also
confusing:</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face="Courier New" size=2>instance Eq Integer where <BR> a
== b = a `integerEq` b</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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".</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Then consider how different a meaning "return" has
in Haskell than it does in C. ;)</FONT></DIV>
<DIV><FONT face="Courier New" size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Does anyone else think this is a problem? If
so, is it fixable?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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. </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>There are many things that contribute to making
Haskell less approachable, the above is just one.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Frustratedly,</FONT></DIV>
<DIV><FONT face=Arial size=2>Sean</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></BODY></HTML>