Expressiveness of Build System Operation DSLs

Operations correspond to what kinds of tasks you can express in your build system’s DSL. Certain types of operations correspond to certain properties, particularly when it comes to dependency expression. CI/CD Failure Strategies and Conditional Execution are other operations that correspond to properties. One type of failure strategy that’s not well represented here is retry as that would be a cyclic CFG rather than a simple DAG. See Build Systems in terms of DAGs and CFGs.

  • Applicative tasks express depencencies that can be determined statically, without computation.
  • Monadic tasks express dynamic dependencies; dependencies that can only be determined by running a computation.
    • Interestingly, this is not the same as glob patterns. Glob patterns are rules of a static structure.
    • lookupInfo >>= compileWithInfo, however, is not a static rule.
  • Functor tasks limit tasks and dependencies to a linear chain. Dockerfiles uses functor tasks.
  • Selective tasks: tasks with conditional statements that can be statically over-approximated.
    • Not truly applicative because the static analysis is not minimal, but not monadic because all possible paths are known in advance.
    • if/then/else conditionals and onFailure failure strategy.
  • MonadFail: monadic tasks that may fail
    • Fully dynamic onFailure strategy that can inspect the failure object to determine the response.
  • MonadPlus, MonadRandom, etc: tasks with certain types of non-determinism
  • MonadState: Tasks that have read and write access to the persistent build information