Constructor and Destructor

In computer terminology, a constructor is some function that takes a list of parameter objects and makes a new object out of these by assembling them into a structure.

A destructor does just the converse, allowing to "destructure" some object into more elementary components.

First, it must be noted that not all components of a structure need be explicitly given to a constructor or returned by a destructor. Actually, for the sake of readability, but also because no system can be founded without (infinitely many) implicit axioms, most of the times, many parameters are left implicit, and taken as obvious from the context, or their value being deferred to some later time.
Second, when some unique objects such as memory (see linear logic) are taken into account as parts of constructions, destructuring the construction to yield the original state of some of these unique objects requires the construction to no longer be available, so that complete destructuration of such an object also means its destruction.
Third, though the algorithmical meaning of objects may come from global properties of complex constructions, the only construction and destructuration operators provided by the programming language may be local, providing no way to safely express these properties.

Of course, all these aspects can be validly combined in many ways, from constructions with every meaningful aspect being explicit non-linear being considered in a one operation (the clean case), to constructions with most aspects being implicit, with semi-explicit linear compounds and no way to have the language automatically group operations in a semantically safe way (which is the dirty case).

For instance, in the traditional "object-oriented programming?" paradigm, the constructor/destructor terminology is used only as relates to the pool of available low-level side-effective resources, with algorithmical aspects of objects being implicit, so that in this point of view, destructuration is destruction. The facts that the traditional C++ model forces all resources, however different and independent, to be considered together when describing construction of objects, in some arbitrary unique of point of view, and that constructors and destructors have to be specified independently from each other, without any provision of consistency being accessible to programmers or checkers, all contribute to make this model as dirty as it could be, and shows to the least the extreme confusion of minds of those behind it.

On the contrary, in traditional typed lambda calculi, constructors are used for objects of high-level semantics, in a usually pure way, where all low-level side-effects are made implicit; the "destructor" terminology is not used explicitly in usual functional programming style, destructors being implicitly used through pattern-matching (which provides a very efficient and expressive way to deal with it); the term is also avoided because it could lead to confusion with destruction of objects, whereas semantically, nothing is destroyed or created, as pure functional objects always exist in some abstract space, whereas the fact that their storage may be reclaimed after they are no more useful is an independent implementational issue.

Of course, storage is no more an independent issue in contexts where resource availability is critical; clean style can then be preserved while allowing full expression of resource-wise constraints by use of Linear Logic, in which constructors and destructors have the combined semantics of high-level algorithmical construction and low-level resource allocation.

Unhappily, our generalized point of view is never explicitly considered, whereas it unifies those above particular concepts, as well as many others. In the TUNES project, faithful to our liberal philosophy?, we strive to enable everyone to have full control on what one may leave implicit or make explicit in any particular program, so that one makes one's own paradigm for available paradigm constructors, so that it destructures in a way that fits whatever program one writes, instead of trying to force everyone to use a one centrally decided paradigm. And controlling what is implicit is precisely what reflection is all about.