Support Enumerations

@danbills commented on Thu Jul 06 2017

It would be nice to restrict types to specific values so that users can only specify one of a limited number of a values.

Per this forum post

---

@cjllanwarne commented on Mon Jul 10 2017

Could be a nice bring-along with https://github.com/broadinstitute/cromwell/issues/2283

---

@patmagee commented on Tue Aug 29 2017

Just wondering if there has been any discussion regarding this.

---

@katevoss commented on Tue Aug 29 2017

@patmagee not to my knowledge but I can start the ball rolling. @geoffjentry & @mcovarr, any opinions on supporting enums?

---

@geoffjentry commented on Tue Aug 29 2017

I’m leery but not necessarily against it. I’m also generally the one with the most conservative opinion in terms of adding WDL syntax, so view that take as a lower bound of acceptance 😃

@patmagee what were you thinking in terms of the syntax?

Pinging @vdauwera so she’s abreast of this convo.

---

@vdauwera commented on Wed Aug 30 2017

FWIW Enum support would definitely be very valuable to us in GATK-world, and are likely to be useful in general.

My one caveat would be that they should be easier to work with than they were in Queue (friendly elbow poke at @kshakir).

---

@patmagee commented on Fri Sep 01 2017

@geoffjentry I share your concern with adding any sort of syntax to the spec, and my first inclination is to fake support enumeration. Im not exactly sure how to do that though, nor am I sure of whether its possible.

The cleanest way I can think of implementing would be maybe something like a Java style enum:

enum MyEnum {
     "A","B","C"
}

workflow wf {
    MyEnum thisIsMyEnum
}

Another way that we would be able to do it would be define an Enum type in a workflow like so:

workflow wf {
     #This would get overridden at run time, but the value would need to be validated
     Enum greeting = ["HELLO","GOODBYE"]
     or
     #Done override anything but validate it
     Enum["HELLO","GOODBYE"] greeting
     
}

---

@katevoss commented on Thu Sep 28 2017

@geoffjentry sounds like this is more of a WDL feature request, shall I move it to the WDL repo?

---

@geoffjentry commented on Thu Sep 28 2017

[jvlasblom]

I’m also interested in having support for enums in WDL. It would help with consistent error reporting, and generating UIs based on declared WDL inputs.

[vortexing]

OK. So right now, someone could specify String output_format = 'dam' and the task would fail for some dam reason, rather than having the workflow fail earlier before the task was actually sent/run b/c ‘dam’ is not one of the FileType’s allowed? That seems like a computational win to me when running someone else’s workflow. Just as long as how it gets done is aimed at newbies b/c the intent is to be more clear to users who don’t already know the enum values for such a param, I’m game.