Closure defined by anonymous assignment has contradictory linting outcome

[ScottNortonPhD]

Bug report

Expected behavior and actual behavior

When assigning a closure to a name inside a process script body, linter should recognize it as a callable. Instead, linter calls it "not defined" on invoke, and "assigned but unused" on definition.

Steps to reproduce the problem

$ cat main.nf
workflow {
    channel.of('world', 'mundo', 'all', 'amigos') | sayHello | view
}

process sayHello {
    input:
    val word

    script:
    def foo = { x -> "hello ${x}" }

    """
    echo ${foo(word)}
    """
}

$ nextflow lint main.nf

Program output

Error main.nf:13:12: `foo` is not defined
│  13 |     echo ${foo(word)}
╰     |            ^^^

Warn  main.nf:10:9: Variable was declared but not used
│  10 |     def foo = { x -> "hello ${x}" }
╰     |         ^^^

Nextflow linting complete!
 ❌ 1 file had 1 error

Environment

• Nextflow version: 25.04.2
• Java version: 23.0.2
• Operating system: macOS
• Bash version: zsh 5.9 (arm64-apple-darwin24.0)

Additional context

This was not an error in LSP v24.10.5.

[bentsherman]

This is allowed in Groovy, and in many other languages like Python and JS, but I am skeptical about supporting it in Nextflow.

Your example is simple enough that the closure is simply not needed:

    script:
    """
    echo "hello ${word}"
    """

Of course, I appreciate that real examples will be more complex, but even then, you can always refactor the closure into a function:

process sayHello {
    input:
    val word

    script:
    """
    echo ${foo(word)}
    """
}

def foo(x) {
  "hello ${x}"
}

I find this much easier to read and understand, whereas the closure is more complicated and doesn't seem to provide much value over a function. But I'm happy to hear you out if you can provide a more convincing example...

[bentsherman]

I think this worked in language server 24.10 because the variable checker was more lenient, but was refactored on the way to 25.04 to be more strict. I think I quietly chose not to support callable local variables, but if we stick to that then we should document it here.

[bentsherman]

Closing since we don't plan to support this pattern. Best practice is to define the closure as a function if you want to re-use it

You can also do foo.call(...) instead of foo(...). In fact this even works with type checking, although I'm still not sure if we should support or encourage it long term.