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

Simplify call syntax: make 'input:' keyword optional #198

Closed
cjllanwarne opened this issue Mar 9, 2018 · 7 comments
Closed

Simplify call syntax: make 'input:' keyword optional #198

cjllanwarne opened this issue Mar 9, 2018 · 7 comments

Comments

@cjllanwarne
Copy link
Contributor

cjllanwarne commented Mar 9, 2018

Today:

call foo { input: x = x_in, y = y_in }

Proposal:

call foo { x = x_in, y = y_in }

Commentary:

I'm sure there was once a grand vision making the input: keyword in a call section necessary, but it turns out it's mostly just noise and yet another thing to remember to get right.

To avoid this needing a breaking change, I suggest we make the keyword optional and encourage people to not bother writing it.

Another potential simplification would be making the commas optional too, eg:

call foo { 
  x = x_in
  y = y_in 
}
@orodeh
Copy link
Contributor

orodeh commented Mar 9, 2018

Sounds good to me. I don't have a problem with the commas though.

@geoffjentry
Copy link
Member

Haven't we seen requests to jam other stuff in that block? If so, and if that happens, how does one discern the difference?

@cjllanwarne
Copy link
Contributor Author

cjllanwarne commented Mar 9, 2018

@geoffjentry this thought was actually keyed off your recent comments about making WDL less complex.

To me this is a classic case of WDL being needlessly picky about syntax to enable "future possibilities" at the cost of making WDL harder to write today.

This keyword obviously isn't a big deal by itself and it's easy to tell you got it right in the IDE, but for a new author in a plaintext editor (and even me sometimes) (1) do I really need it (2) is it "input" or "inputs" (3) do I need a colon after it (4) is there some other section I'm supposed to be including

@geoffjentry
Copy link
Member

@cjllanwarne Oh I totally get that, and things which reduce boilerplate are a good thing. This was more just a make sure it's thought through reminder than a disagreement.

@patmagee
Copy link
Member

I like this idea. Especially making it optional to guard against future issues.
If there are new sections added to the call block, It would be good to keep them as optional modifiers to a call. In this way it would not break any WDL. ie in the simple case you would have the following:

workflow foo {
  call a {
    x = x_in,
    y = y_in
  }

but if you needed any other blocks you would do:

workflow foo {
  call a {
    input:
      x = x_in,
      y = y_in
    some_other_block:
      ###
  }

also, not sure if this is the placae to bring it up, but why on earth is the input block so different then everything else?? why use semi-colons, and why have commas? (it honestly causes me more failed workflows then I care to admin):

workflow foo {
  call a {
    input {
      x = x_in
      y = y_in
   }
}

@vortexing
Copy link

In order of how much I'd benefit from it/be less irritated by it:

  • stop requiring commas in the dang input block when brackets are used. IF I put {, then just keep assuming I'm talking about more inputs even without commas until I give you the next }. Just like in the task definitions. This would allow for other maybe metadata related sections to be added to calls in the future.
  • if you don't user brackets, fine, then don't write input at all, and you'll have to use commas.

I prob wouldn't bother with skipping writing input though b/c for new folks, keeping the formatting the same throughout the entire WDL is likely the least confusing for folks. Just my 2 cents for newbs.

@jdidion
Copy link
Collaborator

jdidion commented Feb 7, 2024

Addressed by #524

@jdidion jdidion closed this as completed Feb 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants