Probably the most fundamental composition mechanism to mention is functional composition. In this paradigm one entity is first encapsulated and parametrized as a functional abstraction, and is then “activated” (instantiated) by receiving arguments that are bound to its parameters. Obviously this compositional mechanism occurs in nearly every programming environment, and is by no means restricted to functional programming languages. Many languages, however, do not allow arbitrary software entities to be treated as values, and therefore do not support functional composition in its most general form.
Parameterized modules, containing variables that can be bound later to other modules, for example, are still absent from many programming languages. At the other end of the spectrum, functional languages use functional composition at every level and therefore provide homogeneity: any aspect of a software fragment can be parametrized and then bound to another component, thereby providing much flexibility for delimiting the boundaries of components. Furthermore, functional programming supports higher-order
composition, i.e. components themselves are data. In consequence, composition tasks themselves can be encapsulated as components, and therefore some parts of the composition process can be automated. Finally, functional composition has the nice property of being easily verifiable, since functions can be seen externally as black boxes: under some assumptions about the parameters of a function, it is possible to deduce some properties of the result, from which one can know if that result can safely be passed to another function. Current functional programming languages have developed sophisticated type systems
to check correctness of composed software.
Leave a Reply