[Haskell] Annoying naming clashes
john at repetae.net
Mon Jun 14 22:05:37 EDT 2004
Another problem is that people learning haskell, especially those coming
from a OO background or language like java, tend to write code that
needlessly exasperates the naming conflict problem.
I think this is because of the initial steps one usually takes in other
languages, the first thing one types when writing java or other OO
languages tends to be something like
1. define the data structures you think you will need or
2. define the class/interface your data structures will have
(which tend to be confabulated together in OO languages)
however, neither of these is a very good way to start a haskell program,
for example, a novice programmer when presented with writing a simple
interpreter might write out (somewhat contrived)
> data Exp = Val Int | Plus Exp Exp | ...
> readExp = readInt <|> readPlus
> readInt = x <- do readInt ; return (Val x)
> readPlus = x <- do readExp; readPlus; y <- readExp ; return (Plus x y)
> interpretExp (Val x) = x
> interpretExp (Plus x y) = (interpretExp x) + (interpretExp y)
however an experienced haskell programmer might realize the data
structure is not needed and just write
> readInterpretExp = readInterpretInt <|> readInterpretPlus
> readInt = do x <- readInt ; return x
> readPlus = do x <- readExp; readPlus; y <- readExp ; return ( x + y)
by getting rid of these needless intermediate data structures (something
you learn to do intuitivly as you use haskell), one reduces the chances
for naming conflicts.
now classes are a bit trickier, the main thing is that classes in
haskell are not like classes in other languages. A class in haskell is
nothing more than a construct allowing you to reuse the same syntax on
different types. (to hopefully do similar things)
Very few actual applications require you to write a class. It is
not that writing a class is particularly difficult or they are
complicated, it is just that they are usually not needed unless you are
specifically writing a reusable library.
The key thing to remember when starting a haskell program is to NOT
write your classes first. just write your program and if you notice that
you are performing similar operations to different types, only then
consider adding a class after the fact. classes should be used to clean
up and refactor existing code, not as a basic building block like in OO
languages.. Haskell is very malliable, it is a lot easier to observe how
your algorithms are being used than to predict how beforehand.
Hope this helps, of course, this is not generally applicable to all
haskell programmers, it is just an observation of how I see new users of
the language try to use it and perhaps get frustrated.
now, if anyone has some insight as to what the first thing you type
should be when writing haskell code.. :) Perhaps haskells concisity
obviates the need for these 'easy choices'. if it were trivial to know
how to start a program then one might say the language is deficient for
forcing you to make the easy decision anyway... but now I am rambling...
John Meacham - ⑆repetae.net⑆john⑈
More information about the Haskell