Describe processes as type transformations, with inference that supports subtypes and parametric polymorphism. Create and query corresponding transformation graphs.
At the moment, parameterized types can only have sub- and supertypes by automatic extension of their parameters' sub- and supertypes. For example, if A <= B, then F(A) <= F(B).
However, it may sometimes be useful to have these types themselves be part of a hierarchy. Broadly, I see the following approaches:
Allow a parameterized type to have a single, non-parameterized supertype. As in, A = TypeOperator() and F = TypeOperator(params=2, supertype=A).
Allow a parameterized type to have a single parameterized supertype of the same arity. As in, F = TypeOperator(params=2) and G = TypeOperator(params=2, supertype=F).
Allow a parameterized type to have an arbitrary supertype.
The use case demonstrated by @simonscheider and @EJTop today (cf https://github.com/quangis/ratios) was to have both ArchimedeanMagnitudes and ProportionalMagnitudes be Magnitudes. This corresponds to option 1. Intuitively, I also think the this one makes most sense. Mixing them would almost certainly be a bad idea.
However, I haven't throught through the implications in terms of the inference. In the meantime, it is possible to emulate such a type by using a TypeAlias with an EliminationConstraint --- the pseudo-supertype A would be interpreted as either one of its parameterized subtypes. So, instead of this:
A = TypeOperator()
F = TypeOperator(params=1, supertype=A)
G = TypeOperator(params=1, supertype=A)
You would do this:
F = TypeOperator(params=1)
G = TypeOperator(params=1)
A = TypeAlias(TypeSchema(lambda x: x [x << {F(_), G(_)}]))
Inferences would then be subtly different. Other relevant issues:
Union types (#106). F(_) & G(_) would be another variant.
Inclusion of aliases in vocabulary (#110). If a supertype is emulated via a type alias, you probably want them to show up in the generated type taxonomy.
At the moment, parameterized types can only have sub- and supertypes by automatic extension of their parameters' sub- and supertypes. For example, if
A <= B, thenF(A) <= F(B).However, it may sometimes be useful to have these types themselves be part of a hierarchy. Broadly, I see the following approaches:
A = TypeOperator()andF = TypeOperator(params=2, supertype=A).F = TypeOperator(params=2)andG = TypeOperator(params=2, supertype=F).The use case demonstrated by @simonscheider and @EJTop today (cf https://github.com/quangis/ratios) was to have both
ArchimedeanMagnitudes andProportionalMagnitudes beMagnitudes. This corresponds to option 1. Intuitively, I also think the this one makes most sense. Mixing them would almost certainly be a bad idea.However, I haven't throught through the implications in terms of the inference. In the meantime, it is possible to emulate such a type by using a
TypeAliaswith anEliminationConstraint--- the pseudo-supertypeAwould be interpreted as either one of its parameterized subtypes. So, instead of this:You would do this:
Inferences would then be subtly different. Other relevant issues:
F(_) & G(_)would be another variant.