If you ask an "ordinary" programmer what is the effect of an
assignment like:
x := <expr>
you will get an answer along the lines: the <expr> is evaluated and
the result is stored in a box named "x".
If you ask him/her whether something else has happened the answer
will usually be "no"; and this is the wrong answer, since one tends
to overlook the fact that one has, by mentioning the variable "x",
also indicated that the old value of "x" is no longer needed. As such
imperative programming is "functional programming with explicit
garbage collection".
This may have been a necessity in the old days, when memory was
scarce and machines slow (in my first course on numeric algorithms we
were taught to declare the variables x, y, z, n, m, i, and j, and the
array a, and to solve our problems with those only; points would be
deducted for making use of more variables, or not reusing whenever
possible!). Nowadays I think everyone agrees that automatic garbage
collection is a good thing; think about the amount of wasted
programmer years of people figuring out where they have space leak,
etc., and users of programs getting a disappointing feeling about
computer science as a whole since apparently we keep delivering
programs that stop to work at unpredictable moments.
So, one might wonder whether assignments are always bad, bringing us
back to the OO discussion. Of course if we have the following
expression:
digest.chew.eat.serve.cook.chop.pluck.kill $ chicken
we all have a definite feeling that after applying the functions, the
original object is no longer available, and the FP view does not feel
entirely natural.
Doaitse Swierstra
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
