nsbgn
commented
1 year ago -
This would mean that, for workflow generation, we always need a pair: an abstraction to express the purpose, and a corresponding implementation to constrain the datatypes. However, this is a good thing: it entails some minor changes to the workflow synthesis code but means that we don't get multiple abstract tools with the same CCT expression (but different implementations) anymore.
-
As it happens, we could use this to immensely simplify the conversion from concrete workflows to abstract workflows. Currently, concrete workflows are a recursive structure of subworkflows, any one of which could be associated with a CCT expression that must be matched against existing abstract tools in the set. Outside the apparent complexity, this also means that any mistake in the CCT expressions means that you must. It is not scalable. If we could instead just manually point to the exact abstract tool in the concrete workflow, we immediately have the correct tool (no need for finicky matching) and we only use the concrete workflow to expand its set of implementations. I don't think it's harder to annotate --- an abstract tool is then just a common name for its CCT expression.
-
This would also be good for the documentation of the tool repository, since we get fewer tools and a clear separation of semantic and syntactic content.
Currently, abstract tools contain both CCT expressions and CCD type signatures. This is a big improvement in clarity over the situation before, in which there was a hodgepodge of sub-/super-/abstract/default tools (with signatures sometimes there and sometimes not).
However, the stated goal of CCT types is to abstract away from implementation details, whereas the CCD types encode some of those details. Therefore, it would be intuitively preferable if CCD types were exclusively present on implementations (that is, on concrete unit tools and multitools) and CCT expressions on abstract tools.