[sidkshatriya]

The nix language is maximally lazy. It does not evaluate things it does not need to. This is good because you don't want it to burn CPU building things (very expensive expressions!!) that it will ultimately not need for final derivation. I'm wondering if guix scheme is suited well for this task:

(a) evaluation is eager

(b) lots of variable mutation.

But perhaps lazy evaluation and lack of variable mutation in guix scheme is not such a problem after all for a nix _like_ system -- I don't know.

[helibom]

I'm still new to both Guile and Guix, but I've been reading the Guile and Guix reference manuals recently and I think some of your concerns about eager vs. lazy evaluation of packages are addressed by Guile's quoting mechanism, more specifically "quasiquote" [1]. This quoting mechanism allows passing around references to package definitions and whatnot, without actually evaluating those expressions until build time. Guix extends quasiquote to create something called "G-expressions" [2], which are even more so fitted to something like the Guix/Nix build system.

1. https://www.gnu.org/software/guile/manual/html_node/Expressi...

2. https://guix.gnu.org/manual/1.5.0/en/guix.html#G_002dExpress...

[atiedebee]

Im very familiar with Nix or the language, but why would interpreting guile scheme for package management be expensive? What are guix and nix doing that would require evaluating everything lazily for good enough performance?

[Hasnep]

It's not the Nix/Guile that's expensive, it's situations like:

    let chromium = pkgs.chromium; in 1 + 1

In a maximally eager language you'd need to wait for the entirety of Chromium to build before you can find out what 1 + 1 is.

[atiedebee]

I checked the spec and Scheme R5RS does have lazy evaluation in the form of promises using "delay" and "force", but I can see why explicitly having to put those everywhere isn't a good solution.

[attila-lendvai]

"lots of variable mutation" is more like "variable mutation is no impossible, but not common".