One of the features of Catlab that I do not yet have a great grasp on how to deal with is how to provide a convenient API for using GAT instances in a consistent way.
That is, there should be a systematic way to expose a compose method that just takes two morphisms, finds the "default" model that they are in, and composes them.
In order to do this, we need a way of attaching "default models" to types.
But there's also a larger issue. In general, the entire context for a term constructor must be passed in to an implementation of that term constructor, not just the arguments to that term constructor. For instance, an implementation of
might require knowing the values of A1,A2,B1,B2 in addition to the values of f1 and f2, because the domain/codomain of a morphism cannot necessarily be inferred from its data.
But in fact, it may be the case that all that is actually needed is the value of B1, for instance. Then the user has to pass in 3 arguments that are not used.
There are a couple possible solutions to this.
One option is to use keyword arguments for the "context" arguments that aren't in the arguments to the term construct. Then if an unneeded one is not actually provided, nothing will break.
Another partial solution is that the user-facing API can be based on the wrapper types, which bundle a morphism with its domain and codomain.
This doesn't need to be resolved urgently, I just thought I'd write down my thoughts so that I and others could refer to them when this finally comes up.
One of the features of Catlab that I do not yet have a great grasp on how to deal with is how to provide a convenient API for using GAT instances in a consistent way.
That is, there should be a systematic way to expose a
composemethod that just takes two morphisms, finds the "default" model that they are in, and composes them.In order to do this, we need a way of attaching "default models" to types.
But there's also a larger issue. In general, the entire context for a term constructor must be passed in to an implementation of that term constructor, not just the arguments to that term constructor. For instance, an implementation of
might require knowing the values of
A1,A2,B1,B2in addition to the values off1andf2, because the domain/codomain of a morphism cannot necessarily be inferred from its data.But in fact, it may be the case that all that is actually needed is the value of
B1, for instance. Then the user has to pass in 3 arguments that are not used.There are a couple possible solutions to this.
One option is to use keyword arguments for the "context" arguments that aren't in the arguments to the term construct. Then if an unneeded one is not actually provided, nothing will break.
Another partial solution is that the user-facing API can be based on the wrapper types, which bundle a morphism with its domain and codomain.
This doesn't need to be resolved urgently, I just thought I'd write down my thoughts so that I and others could refer to them when this finally comes up.