[proposal] Expose ScriptParser as an extension point

[bentsherman]

The ScriptParser class defines how a Nextflow script is executed. It essentially takes a Nextflow script and produces a Groovy class (i.e. BaseScript) which, when executed, builds the workflow DAG.

Exposing this interface as an extension point would serve a number of purposes:

• allow Nextflow to support multiple parser implementations / DSL versions in a modular way (could also be done with a regular interface)

• allow me to develop the formal grammar (#4613) in a plugin, where I can iterate much faster because the build time is so much lower (few seconds vs 30-60 seconds)

• allow community developers to experiment with Nextflow syntax and propose changes in a way that can be easily tested

• in the long term, allow developers from other domains to develop their own DSLs atop the Nextflow runtime (see BEAM and JS runtimes, which can be targeted by many different languages from different domains)

Lots of potential use cases from having this extension point. But for now I mostly just want to have faster build times 😄

[stevekm]

would this enable the development of methods to use CWL to define Nextflow tasks? just wondering, there's a bunch of old issues related to that https://github.com/nextflow-io/nextflow/issues?q=cwl in particular this one https://github.com/nextflow-io/nextflow/issues/545

[bentsherman]

That is a potential use case, supporting other workflow languages like CWL and WDL. Though I would push for something that simply translates them to Nextflow rather than run them directly, so that the user has a chance to make manual refinements and it's clear what is being executed