newbie conceptual question [from haskell list]

[Frank Atanassow]

matt heilige wrote:
> this brings up another issue that has, up to this point, not
> been mentioned... the well-understood (and theoretically guaranteed)
> properties of functional languages allow compilers/interpreters to do some
> much smarter things with functional constructs... this allows very
> abstract language features to be implemented much more efficiently. to
> return to the original question: "why not just write in a functional style
> in an imperative language?" the answer goes beyond the (not
> inconsiderable) convenience of having a syntax designed around the style.

Good point, and this reminds me of another point I wanted to mention.

You can replicate functional features in conventional languages, but you
lose another benefit of typed functional programming: machined-checked
documentation of your code.

When I write a program, I typically know much, much more about that program
than what is expressed in the source code I write. For example, in C I may
know that two procedures do not interfere, or that they are re-entrant, or
that a variable is never aliased. Sometimes knowing these facts is crucial
to maintaining the program. Then you have to make sure that it gets
communicated to the maintainer by stating it somewhere in the documentation.
And you have to make sure that what you're saying is actually correct, or
you end up causing even more confusion. So keeping accurate and up-to-date
documentation is a big part of the task of writing a C program. (I think for
C++ it's probably even more important because you need to define for each
method not only what it does, but what it should do in the future, so that
when it's overridden in a derived class, that contract is followed.)

By writing a program in a typed functional language, you are proving facts
about your program, facts which are encoded in an apparent manner in the
source code itself, and not some external documentation. You are proving
that disjoint programs do not interfere, that order of evaluation doesn't
matter, whether they (reduce to programs which) have effects, etc. There's
also safety, and "theorems for free". Then there are other properties which
are obvious (to a programmer) in a Haskell program which get buried in the
equivalent C(++) program, e.g., that every member of a data structure is
traversed in a fold ("no early exits"). Many of these things hinge on the
typing of a program, which is inferred and checked for you, so there is less
of a burden on conscientious programmers.

These facts always get driven home to me when I program in C or even untyped
functional languages like Scheme. I always seem to end up writing down in
documentation, stuff that I would leave implicit in a typed language,
because its apparent from the source code, and/or automatically checkable by
merely compiling the source code.

---
Frank Atanassow, Information & Computing Sciences, Utrecht University
Padualaan 14, PO Box 80.089, 3508TB Utrecht, The Netherlands
Tel +31 (0)30 253-3261 Fax +31 (0)30 251-3791