Multiple inheritance of signatures

[algebraicjulia]

Multiple inheritance of signatures

[epatters]

My thinking and preferred phrasing has evolved a bit since I first wrote the issue. Mathematically, I would like to think of "multiple inheritance" of GATs with no shared terms as a coproduct of GATs and more generally "multiple inheritance in a diamond" as a pushout of GATs, like we have been discussing lately. So I would hope that this issue can be resolved as a byproduct of our planned efforts in this direction.

Of course, this abstract point doesn't say much about how this stuff will manifest in Julia. Your idea is interesting. It may well be useful to have Catlab generate trait-style types in this situation.

[jpfairbanks]

From the Bartosz discussion

But we could go outside of the subtyping relationship and instead ask whether a cast from E to D would be safe or not. This cast would be safe if D were the bare-bone combination of B and C, with no additional data and no overriding of methods. And, of course, there would be no pullback if there is a name conflict between some methods of B and C.

I think the constraint of "no additional data and no overriding of methods" means no additional data relative to the disjoint union of B and C.

And the requirement that there are no name conflicts between B and C comes from the fact that methods in C++ are referred to by name. If you thought of methods as entries in the method lookup table of the language runtime, then you could introduce new methods automatically.

We ran into a problem like this when we were doing model fusion with named variables, because when you create disjoint unions of models you needed to automatically generate new variable names. This became easier when we switched to just calling every variable X_i because you new what the next available variable name was (i+1). Although then you have to keep track of where that variable came from in the original models, because you don't have a human readable variable name to indicate that structure.

So in a language where the method names are significant, you don't have the property that every span of types has a pushout (cospan/pullback in Bartosz's notation). But if you abstracted out the method names you could actually solve the diamond inheritance problem, at least you could replace the "what should this method be" problem with the "how do I make a useful UX for this weird PL feature" problem.

[jpfairbanks]

Is a traits approach better than multiple inheritance? In a sense we want to say that a category is "dagger compact" if it has both the "compact" trait and the "dagger" trait. In order to set up the traits you make a type for each property and then a function that returns an instance of that type for each instance.

For example

abstract AbstractCategoryTrait end

struct Dagger<:AbstractCategoryTrait end
struct NoDagger<:AbstractCategoryTrait end

So if c was a dagger category, you would have some daggertrait(c::DaggerCategory) = Dagger() otherwise daggertrait(c::Category) = NoDagger() then the methods that you want to apply to dagger categories only have the signature

function f(::Dagger, c::Category, args...)
   # actual implementation assumming c is dagger
end
function f(c::Category, args...)
   f(daggertrait(c), c, args...)
end
function f(::NoDagger, c::Category, args...)
   error("f only applies to dagger categories")
end

[jpfairbanks]

Yeah if we implement GATs as sets of traits, then the pushout of a span of GATs should be implemented as the pushout of the sets of traits. Do pushouts actually solve the diamond inheritance problem? I never thought it that way, but it seems kinda obvious now. Dumas, 2005 considered the issue: https://arxiv.org/pdf/cs/0510057.pdf.

The commutativity of the pushout square means that both interpretations of the A that are "inside" D have to agree. I guess that solves the hard parts of the diamond problem by setting a limit on how four classes have to interact with each other, the two derived classes B and C have to be consistent in their treatment of A.

          A
        /   \
       B     C
        \   /
          D

For example if we think of the maps A->B and A->C as being 1-1, then in order to form D you can't have overloaded the same method of A with different methods in B and C.

[epatters]

Thanks for the reference. Googling a bit, I see that Bartosz also discusses the connection with multiple inheritance on his blog. (His arrows go in the other direction, so he talks about pullbacks instead of pushouts, but of course this is a matter of convention.) Similarly to the paper, in the context of C++, Bartosz makes the connection specifically to virtual inheritance.