Does this imply that at one time the compiler would have been affected by such a redefinition? and that <: is not generic for historical reasons relating to that? Considering almost all functions in Julia are generic I am curious as to why <: and a few other functions aren’t generic.
Mostly no. Inference has always (since a long time ago at least) have it’s own version of all the functions.
Certainly no.
Because there has to be these functions. These are just operations that you have to be based on. A language with only semantics without any operation is quite useless.
However, they doesn’t have to be user facing functions. As I said, you can define issubtype as the builtin function and define your favorite operation by calling that. It’s exactly how many other functions are defined. You see a few of these simply because they are good enough as is and it’s mostly an implementation detail.
1 Like
Certainly one could rename <: to issubtype, unexport it, define <:(X, Y) = issubtype(X, Y) and then export that. But would you really want an overloadable <: operator that doesn’t match the actual subtype relation? What good would that do? With getproperty the x.f syntax is the entire point. Nobody cares if you can write X <: Y and have it return true—they care about whether X actually behaves as a subtype of Y.
So the question of why <: isn’t a generic function is really “why can’t I define the subtype relation—and therefore dispatch—in completely user-defined arbitrary ways?” Which seems like it answers itself. If <: were arbitrarily user-definable how would one even guarantee basic things like that it is a predicate (always returns a boolean), and that it satisfies properties like reflexiveness and transitivity? Not to mention all the other properties that are necessary for a sane subtyping and dispatch system.
4 Likes