Switch statements

[dakom]

Description

There is already an open issue for if statements at #608. This can be considered an alternative proposal since it would cover that use-case as well, but it really speaks to a different use-case of branching on multiple variants of a single test. That's a bit wordy, let's look at an example :)

Imagine we have if and we want to run different tasks depending on a DEPLOY_ENV var. We could model it like this:

tasks:
  deploy:
    deps: [deploy-prod, deploy-staging, deploy-dev]

  deploy-prod:
    if:
      - sh: '[ "{{.DEPLOY_ENV}}" = "prod" ]'
    cmds:
      - echo "Deploying to production"
    
  deploy-staging:
    if:
      - sh: '[ "{{.DEPLOY_ENV}}" = "staging" ]'
    cmds:
      - echo "Deploying to staging"

  deploy-dev:
    if:
      - sh: '[ "{{.DEPLOY_ENV}}" = "dev" ]'
    cmds:
      - echo "Deploying to development"

However, there's a few problems:

1. The overall logic is spread among a bunch of tasks, it's hard to see what's happening as we add more
2. It's too easy for the subtasks to add their own additional logic, which can drastically impact the ability to reason about what's going on
3. There's no exhaustiveness checks.

In other words, if works well enough for one or two small "branches", but it gets too unwieldy at scale.

What if instead, we had switch, and it looked like this:

tasks:
  requires:
      vars: [DEPLOY_ENV]
  deploy:
    - switch "{{.DEPLOY_ENV}}"
      - case "prod"
        - cmds:
          - echo "Deploying to prod"
      - case "staging"
        - cmds:
          - echo "Deploying to staging"
      - case "dev"
        - cmds:
          - echo "Deploying to dev"
      - default
        - cmds:
          - echo "Unknown deploy target {{.DEPLOY_ENV}}"

Solves all those problems:

1. It's all located together
2. The case matching is done on only the specified switch, no room to introduce hidden logic
3. Exhaustiveness checks with default

Much cleaner imho!

Complex conditions can be done by assigning some output to a var and switching on that, though if really helpful, this would be cool too:

tasks:
  deploy:
    - switch
      - sh: task some-complex-assignment
      - case "prod" # not sure about indentation here
      ...

But I don't think that's necessary, running the sh assignment to a local var is totally fine

(btw, just for the sake of completeness, this exact problem could be solved by just having subtasks and running task deploy-{{.DEPLOY_ENV}} but it's just an example, real-world problems aren't always so trivial)

[trulede]

What about:

tasks:
  requires:
      vars: [DEPLOY_ENV]
  deploy:
    tasks:
      deploy-prod:
        if: '{{eq .DEPLOY_ENV "PROD"}}'
      deploy-stage:
        if: '{{eq .DEPLOY_ENV "STAGE"}}'
      deploy-dev:
        if: '{{list "PROD" "STAGE" | has .DEPLOY_ENV | not}}'

That can be done with 20-30 lines of code, leveraging the existing precondition handling, and adding a slight behaviour change for the if behaviour (i.e. not causing an error if the condition fails). Looking at it now .. the way preconditions operates is not an exact analog to how if might work.

Using the templating engine, which is very capable, as an alternative to the sh (shell), which is also capable, could be more fluid in operation. Also, there is a question of complex logic (if/and/or) and how that would be best handled ... for instance ... in the condition itself - so the templating or sh takes care of that, since it already can, and therefore the Task schema does not become a programming language.

If you want a programming language ... I would suggest embedding a LUA runtime into Task.

[dakom]

@trulede - I gave an example of using if in the original post and noted several problems with it. You've addressed the first one of subtasks but it's much more than that:

2. It's too easy for the subtasks conditions to add their own additional logic, which can drastically impact the ability to reason about what's going on
3. There's no exhaustiveness checks.

switch would solve those because you're matching against a single value, and exhaustiveness checks can be had by requiring a default

this doesn't need an entirely new programming language, if anything it's more declarative and template-like than if since the control flows by comparing against a single value.

for one example in the wild of its use in a template engine, see the syntax from askama (it's far more powerful since it's using Rust-like matching, but it's the same as switch if you squint): https://askama.readthedocs.io/en/latest/template_syntax.html#match

[pd93]

Task is primarily declarative. We have added limited support for programmatic primitives like for to help reduce boilerplate, but I personally wouldn't want to take this much further. Bear in mind that the proposal for if is not for a complex "if this, then that" style logic within tasks. It is to add a set of conditions which dictate if an entire task should be run (like preconditions/status etc).

I'm also not a huge fan of the suggested syntax. Many nested layers of arrays is confusing and doesn't read well IMO. It is inherently difficult to build programmatic support for things in data formats like YAML without being incredibly verbose. Even the for keyword is too confusing sometimes, and I authored that change.

If you have a requirement for programmatic tasks that go beyond the functionality Task provides, maybe Task isn't the right tool for the job. Whether it be shelling out to a proper language or using a more programmatic-oriented task runner such as Mage/Gulp.

I will leave this open for now to gather upvotes and other opinions.

[dakom]

@pd93 - Please reconsider the actual proposal, not the name... "switch" here is more like a match expression in Haskell than a switch in C. It's far more declarative than the if proposal.

We can call it "match" instead of "switch" if you prefer.

The point is that you have a single value and then you map that to a single branch.

If you prefer functional programming terms (what's more declarative than that?) consider the "switch" family from RxJS or the "switch" function in more authentic Functional Reactive Programming implementations like Reactive Banana

To be clear - I'm not suggesting to add a full FRP implementation in Taskfile(!), I'm just saying that switch (or match) can absolutely be written in a clean declarative way and insist on zero side-effects and would make writing Taskfiles easier

[dakom]

(personally, I like "match" more since I typically code in Rust and use askama for templating, but that would hint to more complexity than I'm proposing here, i.e. pattern matching, which is not what I'm suggesting - I'm suggesting matching in direct equality only, much simpler)