Chris Rackauckas throws out a slew of interface-related points in this Discourse thread that seem really relevant to this notion I have in my head of function/relation/predicate intersectionality.

For example, == being required to return a Boolean…unless a missing is involved in the comparison, in which case a missing is returned. Is that wrong? Bad punning? Maybe! It kind of depends on what we decide == means and whether that’s useful. Fortunately(?), if we decide that namespacing gives the final say of semantic meaning of a function/relationship/predicate, the worst-case scenario for competing names is that a package uses their own definition and articulates what they mean by it.

In the case of == and missing, I actually think “borrowing” the meaning of Base.== makes sense and that it shouldn’t be restricted to only Boolean outputs:

• If we’re strict about enforcing ==’s outputs to be Booleans, then missing has no semantically-correct implementation of ==, because the whole point of the type is that you don’t know what it is and can’t make comparisons to it—three-valued logic is the crux of what it is/means.
• That would mean we have to instead have a special three-value logic == instead (e.g. Missings.==). Which…now that I’m writing it out, maybe isn’t the worst idea in the world? I guess it saves Base.== from having a loose, “any kind of equality you can think of” definition. And what if we want to model four-value logic, should Base accommodate that as well? Huh.
• Maybe the real drawback here is that, from a syntax/usability standpoint, it’s a pain to intersperse two different equality definitions in the same code without confusion, but it’s also sucky to loose out on the tenseness of a well-recognized symbol like ==. There might be a few solutions to that—one might even be to make it easier to specify what namespace you’re pulling from closer to where you’re writing the code, instead of at the top of the file?

Maybe this leads into a larger question of “who primarily handles specialization: entities(/types) or relationships(/functions/predicates)?” My gut reaction was to pawn it off on entities, but maybe it should be handled by more nuanced/redefined relations?

Looking through some of the challenges with array interfaces and indexing and stuff might lead to some more insights here.

One additional metric for generalizing any patterns here is how they actually get used. One of the cool things that Julia seems geared towards is highly generic code, where you can define a function as a composition of other functions and that allows it to “just work” on new types. But that composability kind of breaks down if we start having to use different functions (instead of different types) to do the thing that we want, because Julia dispatches just one semantic function based on type—you can’t suddenly say “I want to use namespace X’s definition of foo if I see type Y.”