3 ms·

I don't mind the nix language, and I far prefer it to lisp. But something I haven't understood is that nix compiles to derivations. I don't think it would be d

I don't mind the nix language, and I far prefer it to lisp. But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations. It would be able to use stuff from nixpkgs as well, at least partially anyway. The built derivations are an extremely simple format anything can produce.

aidenn0 3y ago
If I understand correctly, Guix can do this. Of course the derivation is the final output, so you lose all of the nix modules and nix packages, which kind of defeats the purpose of using NixOS.
- georgyo 3y ago
  I don't think you nessairly need to give up interop. Kinda like his JavaScript can call wasm modules. The compiler would need to know how to use nixpkgs, but the user could write their derivations any way they see fit.
  - aidenn0 3y ago
    You can depend on other derivations rather easily, but interoperating with functions written in the nix language is more challenging. (And without nix language interop, basically all of NixOS that isn't nixpkgs is useless).
pxc 3y ago
> But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations This is originally how Guix worked— it generated .drv files in the same format as Nix and then asked a Nix daemon to build them. But both projects consider the derivation format an implementation detail that should be free for them to change according to the needs of the rest of the stack, rather than a stable interface for downstream consumers (be they end users or other software tools). The above is not just theoretical— as a result, the derivation formats of the two projects have diverged. (Tbh I agree with their position, though. I don't think the concept of the derivation should really be visible to end users. The way the term is used is extremely overloaded/ambiguous, and so at the end of the day it's jargon that serves more to obscure than to teach.)

aidenn0 3y ago

If I understand correctly, Guix can do this. Of course the derivation is the final output, so you lose all of the nix modules and nix packages, which kind of defeats the purpose of using NixOS.

georgyo 3y ago
I don't think you nessairly need to give up interop. Kinda like his JavaScript can call wasm modules. The compiler would need to know how to use nixpkgs, but the user could write their derivations any way they see fit.
- aidenn0 3y ago
  You can depend on other derivations rather easily, but interoperating with functions written in the nix language is more challenging. (And without nix language interop, basically all of NixOS that isn't nixpkgs is useless).

pxc 3y ago

> But something I haven't understood is that nix compiles to derivations. I don't think it would be difficult to have a nix compiler that takes Lisp or whatever and spits out derivations This is originally how Guix worked— it generated .drv files in the same format as Nix and then asked a Nix daemon to build them. But both projects consider the derivation format an implementation detail that should be free for them to change according to the needs of the rest of the stack, rather than a stable interface for downstream consumers (be they end users or other software tools). The above is not just theoretical— as a result, the derivation formats of the two projects have diverged. (Tbh I agree with their position, though. I don't think the concept of the derivation should really be visible to end users. The way the term is used is extremely overloaded/ambiguous, and so at the end of the day it's jargon that serves more to obscure than to teach.)