| Thanks for pointing to MDL: http://www.ifarchive.org/if-archive/infocom/info/MDL_Primer_... Nevertheless, the MDL UNWIND and the later UNWIND-PROTECT are more limited in applications and they require much more work from the programmer than the mechanism introduced by Stroustrup in 1980. With implicitly-invoked destructors, the destructor body is written once for each type of data, and normally there is no need to ever invoke it explicitly. After writing correctly the constructors and destructors, the programmer's work becomes identical with using a garbage collector, because the objects are allocated explicitly, but they are never deallocated explicitly. On the other hand, UNWIND is intended for handling exceptions. It can also be used as a normal cleanup strategy, but it still must be written every time for handling the exit from a block or from a hierarchy of nested blocks. In the latter variant, there is some economy in code writing, but the lazy deallocation is less efficient. The UNWIND of MDL has little resemblance to RAII, but it resembles the UNWIND of Mesa (programming language used at Xerox, starting with 1976, which has introduced many innovations that have been included only much later in most programming languages). It would be difficult to determine whether UNWIND has appeared first in MDL or in Mesa, or if both have taken it from another language, because experiments with exception handling were fashionable during those years and there were many places where various variants were tried. |
Resource management in the MIT Lisp OS ca. 1980, approximate example.
One would define a resource of arrays, where arrays can be allocated and deallocated. They will be managed via a pool.
Now user code would use the USING-RESOURCE macro, where it spans a dynamic scope. Entering the scope allocates the resource. Inside the scope the resource is allocated. Leaving the scope will automatically deallocate the resource and put it back into the pool. A deinitializer may free memory as needed. To make sure that the resource gets deallocated, the above macro form will expand to something using UNWIND-PROTECT: This is an example of manual memory management using a pool of resources, where the DEALLOCATE is done always via UNWIND-PROTECT.Thus the user will not explicitly use UNWIND-PROTECT, but some macros which use it in their expansion...