Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Else statements #697

Closed
claymcleod opened this issue Jan 20, 2025 · 7 comments
Closed

Else statements #697

claymcleod opened this issue Jan 20, 2025 · 7 comments
Assignees

Comments

@claymcleod
Copy link
Collaborator

I recently discovered that WDL does not have else statements. To achieve the same effect, it's suggested by the spec to use two if statements: one with the conditional you desire, and then one with the negated conditional.

Searching through the issues, I didn't immediately find an explanation as to why we can't have else statements. Is there a good reason for this that I just can't find?

@geoffjentry
Copy link
Member

I actually remember this one.

It's because there were a lot of strong motivating use cases (in terms of scientific workflows people were actually trying to run at the time) for "optionally run a task" but very few for deeper branching logic. Because that impact prioritization plus how it would complicate both WDL & implementation and that "design a full programming language" was an explicit non-goal we left it at just the if.

Most of these boil down to some form of there not being enough of motivating use cases to be worth the extra effort. Sometimes this was IMO for the better (e.g. the lack of loops: 10 years later and still doesn't come up hardly at all) and some for the worse (e.g. Pair which only exists as a half-ass on richer object types due to key use cases at the time only needing pairs of things)

@claymcleod
Copy link
Collaborator Author

claymcleod commented Jan 20, 2025

Yeah that totally makes sense, thank you for the context and the history here.

I don't know if you've been following the work I'm doing on the wdl-docs repository, but I definitely think that this minimalism is a strength (in particular, this section). I totally agree on loops that they are probably not needed.

Though I 100% agree that WDL should remain simple and should not often "purchase" flexibility at the cost of more complexity, to my eye, else would add a relatively very small amount of complexity while enabling a moderately useful design pattern in a more straightforward way. For example, doing things like in the the second example here are probably going to be much more straightforward with an else clause.

@patmagee
Copy link
Member

I think an else statement is a complimentary pattern to an if statement and it is really awkward to have one and not the other. If we are going to allow branching, we should not shortchange the end user IMO.

Without it, I will often see things like:

if ( condition x){

}

if (not condition x){

}

@geoffjentry
Copy link
Member

A question I'd have is: if one were to survey the world's breadth of public WDLs, how often do you see the above?

If the answer is "a lot" (for some definition of "a lot") then I agree. If the answer is "not a lot" (for some definition of "not a lot") then I disagree.

I don't think we should be in the business of trying to build out every typical language construct and instead focus on improving awkwardness caused in the real world due to language limitations.

@claymcleod
Copy link
Collaborator Author

claymcleod commented Jan 25, 2025

I don't think we should be in the business of trying to build out every typical language construct and instead focus on improving awkwardness caused in the real world due to language limitations.

Perhaps I can do some surveying using gauntlet.

On the other hand, there is another virtue—as we consider adding new language features, such as the high likelihood of enums being pulled in, I think it is okay, to an extent, to add in features preemptively when we anticipate they are going to be needed alongside those new features, so long as we have the discussion on balancing the introduced complexity.

If we're not already there for a language need of else and perhaps else if, I would make the argument that adding enumerations is going to push us over the top in terms of a need for larger conditional blocks that are mutually exclusive. In the spirit of your point above, though, I'm not reaching for more complex constructs like a switch/case statement.

Last, for the else statement in particular, I would submit that this is simple enough and common enough that it shouldn't be scrutinized so closely as an added burden to users of the language: else is at a level of notoriety in programming languages in general that it's more of a mental burden for users to remember that it doesn't exist in WDL than if it did exist. Anything more complex than this concept, such as list comprehensions, enumerations, switch statements—sure, they should all be scrutinized much more heavily in terms of the tradeoff.

@geoffjentry
Copy link
Member

One can say that about anything. There's no real need to fill in every standard PL blank here. Personally I'd reach for an internal DSL if I wanted a fully baked PL, not an external DSL.

@claymcleod
Copy link
Collaborator Author

claymcleod commented Jan 26, 2025

It's possible that others might try to use the same argument, and, of course, they're welcome to do that: each decision on a feature needs to be based on an evaluation of the added utility vs. the added complexity. Those evaluations, in turn, should be discussed on a case-by-case basis with the broader context of WDL's values.

Here, I'm arguing that complexity is removed with the addition of else and else if—a claim that is quite unique, as I can't think of many other features where that could be successfully argued. Examples such as the one Patrick gave above (which we run into quite a lot too, as I did with writing the docs) and the nearly inevitable future inclusion of enums make the case stronger.

Last, I noticed #268, which appears to have had quite a bit of community support prior to this issue. I'm going to close this issue in favor of that, but I'll note here I intend to invest some time on a proof of concept that can be more formally reviewed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants