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