#pure functions

Symlinking package schemes such as GNU Stow have been around for a while. The Nix package manager formalizes and extends these ideas.

This 2013 Ludovic Cortes paper on GNU Guix provides a good overview on it's goals and methods, starting with a general description of the Nix package manager:

No side-effects (akin to "pure functions"). Each derivation (the description of a specific build) is excuted in a chroot.

Referential transparency as a result of:

Defined inputs mapped to outputs in an immutable /nix/store directory (known as the store by a hash function (akin to on-disk memoization(*)

Transactional.. even with an interruption we know exactly what state we are in.

Each user has symlinks to the immutable /nix/store which allows individuals to mix-n-match unique configurations but to share the disk-space to the specific immutable entity.

The builders in NixOS often use BASH

The store is garbage collected

RPC is used to synchronize operations on the store by builders.

The Nix interpreter is C++ originally and uses its own Domain Specific Language for the derivations. GNU Guix replaces this DSL with its own Scheme-based one, but keeps the Nix primitives for the builders.

The Guix derivations explicitly expose more low-level inputs.

Guix replaces the use of NixOS BASH + find + sed with its own modules. These include separate builders for e.g. PERL.

NixOS relies on /bin/sh being in the chroot, GNU Guix does not. Instead it manually substitues them with correct shebangs from the store, e.g. /unix/store/what/ever/98uaf8u8w-bin.sh . This has the advantage of being both more pure, and also allowing other shells such as dash to be executed.

All identity functions do is return the first argument given to them:

var identity = function(arg1) { return arg1; };

This doesn't sound too useful, but it actually can simplify code quite a bit. Firstly, here is a simple inheritance structure of two objects. One that defines base API methods and one that represents one API location:

var BaseAPI = function() { var self = {}; self.baseUrl = '/test/:location'; self.getUrl = null;// Set by child self.send = function(callback) { var url = this.baseUrl; if (typeof this.getUrl === 'function') { url = this.getUrl(url); } // Simulate API call by making the code asynchronous. setTimeout(function() { callback('Called with ' + url) }, 200); }; return self; }; var CarApi = function() { var self = Object.create(BaseAPI()); self.getUrl = function(url) { return url.replace(':location', 'cars'); } return self; }; var api = CarApi(); api.send(function(resultMessage) { console.log(resultMessage);// Called with /test/cars });

All the child has to do is change the URL by overriding a function to define custom behavior. But for each function customization that the BaseApi will need to support, a new if check needs to be added. If instead the getUrl starts as an identity function, the send call in BaseApi can be simplified:

var BaseAPI = function() { var self = {}; self.baseUrl = '/test/:location'; self.getUrl = identity; self.send = function(callback) { var url = this.getUrl(this.baseUrl); // Simulate API call by making the code asynchronous. setTimeout(function() { callback('Called with ' + url) }, 200); }; return self; };

So when code is written as a set of one argument Pure Functions, behavior customization can be simplified. Identity functions are available in many libraries like Lodash.