Features like IFD are useful in build systems because they allow build systems to be Monadic, in the words of the Hadrian paper: build things to decide what to build. By comparison, an Applicative build system such as Bazel can only take in things that are known statically; in Bazel it is thus common to check in generated build instructions. This property in category theory is illustrated in the type signatures of the operations of Monad and Applicative:
#nix
https://dl.acm.org/doi/10.1145/3241625.2976011
https://jade.fyi/blog/nix-evaluation-blocking/
@xameer IFD makes the Nix language a Monadic build system. RFC 92 dynamic derivations make the derivation layer a Monadic build system, so that the language doesn't suffer from the disadvantages of Monadicity, such as having to keep the language evaluator alive while building.
cc the author @Ericson2314
@roberth @Ericson2314
> evaluation is inherently sequential (at least in the current implementation), while only realization is parallel. This means that builds with multiple cases of IFD do not scale well because they happen strictly one after the other.
Via nix academy
Is this still correct?
@xameer @Ericson2314 Yes. Parallelizing evaluation doesn't scale very well and tends to require user-provided hints (like a Haskell-inspired par function), whereas a derivation graph is trivially concurrent.
I also suspect eval parallelism may interfere with an improved eval caching strategy, but this is speculative.
Speaking of speculative, par is speculative execution :D (the mostly good kind, not the fragile CPU kind)