Should enums with identical structure but defined in separate locations be considered the same type?

[mr-c]

From common-workflow-language/cwltool#308 (comment)

[mr-c]

Related: #443

[LourensVeen]

Ah, interesting!

The programming languages that I know of all have the same solution that if I understand correctly CWL currently has, where a type is defined in one place, and then imported wherever else it's used. That means you get to keep your namespaces, and there is no potential for problems when people start combining CLTs from different sources. However, as the other thread shows, people expect those two types to be the same.

I think a good solution could be to introduce the concept of compatible types. If type A is compatible with type B, then any value of type A can be used anywhere a value of type B is expected, it being converted implicitly. And vice versa. Like how you can pass an int to a function expecting a float in many languages.

That means that the two enum definitions would actually define different types (with the same name but in different namespaces), so that we avoid clashes, but being identical, they're compatible, so you can still pass a value of one type into an input of the other type.

Then the question is how to decide whether two types are compatible. Being identical would definitely be good, and the natural way to define it is using Liskov subtypes (this is literally Liskov substitution), but can we derive that from two custom type definitions?

[serge2016]

@LourensVeen could you explain, please, about what clashes are you talking? In the type field of any enum I do specifay what exact strings it should accept! And I do not need/mean/want any changes to that strings occur. The enum "symbols" are not ids! There is no place in the CWL spec, where it is said they should be unique or should be processed as ids!

[LourensVeen]

I'm thinking a bit more generally here. What if you workflow had

  enum_workflow_input:
    type:
      name: "foo"
      type: enum
      symbols: ["a","b","c"]

and the command line tool that you're calling has

  enum_workflow_input:
    type:
      name: "foo"
      type: enum
      symbols: ["a","b","c", "d"]

With different definitions, we can't consider them the same type for sure. So should that give an error message, because we have two types with the same name but defined differently? Does it matter whether the two definitions are identical or not? Maybe we should be allowed to have as many copies of a type definition as we want, but only as long as they're identical? Or should this be okay regardless of whether they differ or not, because one is really workflow.cwl#foo and the other is task.cwl#foo, so there are simply two different types with different names here?

One option, which is maybe how you see things (?), is to consider type checking simply schema validation. So that means that in your example, we have an input object, which is a string with a particular value, which is first checked against the workflow.cwl#foo schema, passes that check, is passed on to task.cwl, where it's checked against the task.cwl#foo schema, and passes again.

Its type is still string, and as long as it passes all the schemas it meets along its way through the workflow, we don't care whether those different schemas are actually compatible in theory, we'll just check values against them at runtime, and if they're incompatible, then no value will pass, but the workflow will still be valid.