Currently, we compose Decapodes together using untyped wiring diagrams. The lack of types allows for generic expressions that are quick to write. Further, type-checking is enforced when oapply is called. i.e. An error is thrown when trying to identify a 0form with a 1form in oapply.
However, such errors occur rather late in the workflow. They could instead occur at the time of composition diagram construction, instead of application. We would gain the myriad benefits that generally come from using types, even without imbuing the type checking with any special rules from the DEC.
So, we should add support for typed wiring diagrams, while maintaining our current level of support for the untyped case.
Special attention must be paid to the infer, Constant, and Parameter types. The PR which closes this issue must decide whether to allow identifying Constant with a 0Form and so on at the composition level. Or whether to allow tagging variables as Parameter at the composition diagram level whatsoever, etc.
Currently, we compose Decapodes together using untyped wiring diagrams. The lack of types allows for generic expressions that are quick to write. Further, type-checking is enforced when
oapplyis called. i.e. An error is thrown when trying to identify a0formwith a1forminoapply.However, such errors occur rather late in the workflow. They could instead occur at the time of composition diagram construction, instead of application. We would gain the myriad benefits that generally come from using types, even without imbuing the type checking with any special rules from the DEC.
So, we should add support for typed wiring diagrams, while maintaining our current level of support for the untyped case.
Special attention must be paid to the
infer,Constant, andParametertypes. The PR which closes this issue must decide whether to allow identifyingConstantwith a0Formand so on at the composition level. Or whether to allow tagging variables asParameterat the composition diagram level whatsoever, etc.