This simplifies type_jkind_sub to just take a jkind to check against, rather than a higher-order parameter telling it what check it should do. The reason for the previous approach was to allow this function to be used for general kind checking (where the higher order parameter compared two jkinds) or just externality checking (where the higher order parameter compared just the externalities of the kinds).
That complexity is unnecessary - externality checking can be implemented as general kind checking with the appropriate kind (any mod <externality>). And this has benefits: in the short term, it means only one function (check_type_jkind) needs to understand the somewhat complicated result type of type_jkind_sub. And in the medium term it will simplify the implementation of product layouts, where type_jkind_sub wants to traverse the layout deeply.
(This is orthogonal to #2676 and looking quickly the small jkind edit here doesn't overlap with that PR so it shouldn't cause a conflict)
This simplifies
type_jkind_subto just take a jkind to check against, rather than a higher-order parameter telling it what check it should do. The reason for the previous approach was to allow this function to be used for general kind checking (where the higher order parameter compared two jkinds) or just externality checking (where the higher order parameter compared just the externalities of the kinds).That complexity is unnecessary - externality checking can be implemented as general kind checking with the appropriate kind (
any mod <externality>). And this has benefits: in the short term, it means only one function (check_type_jkind) needs to understand the somewhat complicated result type oftype_jkind_sub. And in the medium term it will simplify the implementation of product layouts, wheretype_jkind_subwants to traverse the layout deeply.(This is orthogonal to #2676 and looking quickly the small jkind edit here doesn't overlap with that PR so it shouldn't cause a conflict)