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.

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.