[clean-list] Clean's answer to the Functional Achilles-heel

Marco Kesseler m.kesseler@aia-itp.com
Wed, 2 Jan 2002 16:02:36 +0100


----- Original Message -----
From: "Mark Phillips" <mark@austrics.com.au>
> Am I right in thinking that whereas older functional languages
> had the "code reuse" problems described above, newer functional
> languages have mechanisms which allow these problems to be
> overcome?

As far as I can see this is simply a matter of:

- If you expect to make frequent additions to a type, do not use
unions/algebraic data types because with each type change you have to adapt
all functions that access this union. Using a union type (without resorting
to the ultimate union - Dynamic) is even impossible for modules that do not
know the complete type at compile-time. Instead define some interface on the
type, and implement that for each type addition (and typically, IO systems
deal with lots of evolving/unknown types). In Clean, interfaces more or less
come in the form of classes/overloading and Existential types.

- If you expect to add all kinds of functionality to a rather fixed type, an
interface might be a bad idea if adding new functionality means extending
all interface instances. Instead you could use a union/algebraic data type,
so that each functional addition can be put in a single function.

I do not know why this has anything to do with code reuse. To me it seems
more a matter of trying to keep (expected) changes localised to a single
module. Anyway, there is no inherent code reuse problem associated with
functional programming. Good old higher-order functions offer a great way
for code reuse.

regards,
Marco

----------------------------------------------------------------------
Aia Software B.V.                      Phone:   +31 24 371 02 30
PO Box 38025                             Fax:   +31 24 371 02 31
6503 AA Nijmegen                         URL:   http://www.aia-itp.com
The Netherlands
----------------------------------------------------------------------
This E-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this E-mail in error please notify
the postmaster (postmaster@aia-itp.com). The authenticity of this
message cannot, at this moment, be guaranteed by ourselves. For this
reason no legal rights may be granted should the contents differ to
the original sent message. The Aia log-file of sent messages is deemed
to be the sole, true transcript of communication unless the contrary,
other than the received message, can be proven.
----------------------------------------------------------------------