Notes on Semantics of Multiple Inheritance (Cardelli, 1985)

notes, papers

This post comprises of my notes while reading Luca Cardelli’s 1985 Paper, Semantics of Multiple Inheritance. At the time of writing, a copy of this paper was available for free from ScienceDirect.

These notes are semi-structured, and are intended primarily for my own reflection.

Section 1 -

Here’s a statement that excites me:

The aim of this paper is to present a clean semantics of multiple inheritance and to show that, in the context of strongly typed, statically scoped languages, a sound typechecking algorithm exists. Multiple inheritance is also interpreted in a broad sense: instead of being limited to objects, it is extended in a natural way to union types and to higher-order functional types. This constitutes a semantic basis for the unification of functional and object-oriented programming.

Section 2 - Objects as Records

Section 3 - Records

Section 4 - Variants

The beginning of this section refers to a “disjoint sum”, This made sense to me after reading this page on and this explanation of Disjoint Union from Wikipedia. I believe that a ‘disjoint sum’ is just an element in the disjoint union of the two sets in question.

Section 5 - Inheritance Idioms

The first comment in this section is interesting - it shows that inheritance, as defined so far in the paper, is an implication of definitions, and need not be declared explicitly.

There is a paragraph: “The subtype relation only holds on types, and there is no similar relation on objects. Thus we cannot model directly the subobject relation used by, for example, Omega (Attardi, 1981), where we could define the class of gasoline cars as the cars with fuel equal to "gasoline.” This sounds like the author is talking about “dependent types” as used on the wikipedia page for dependent types.

The next paragraph after that introduces a solution by defining a set of fuel types and then defining “gasoline_car” as a subtype of “car”. My gut is that this sort of compile-time-versus-runtime type-checking (and type-definition?) distinction is related, at some level, to the “code versus data” issue that Lisp (partially?) addresses through homoiconicity.

Interesting note, in that “constructor” is “a vague term indicating that, in an implementation, computation can be temporarily suspended thereby avoiding some looping situations”. This makes me wonder; how does object initialization (construction) work in Ruby?

Possibly to be continued

[Note 2018-05-06] The paper has another 7 sections or so, but I put down and temporarily abandoned process back in December of 2017. I decided to publish these notes anyway, again, mostly for my own reflection and reference.

I'm looking for better ways to build software businesses. Find out if I find something.