Add draft "Rosetta stone" by @fricklerhandwerk and stub commentary

The idea and most of the execution are @fricklerhandwerk's. I changed a
few things best I could based on @edolstra's corrections, and a Bazel
glossary.

Valentin Gagarin <valentin@fricklerhandwerk.de>
This commit is contained in:
John Ericson 2022-04-22 01:39:30 -04:00 committed by Valentin Gagarin
parent c86c1ec7e3
commit 0737094161
3 changed files with 61 additions and 1 deletions

View file

@ -26,7 +26,8 @@
- [Input-Addressing](design/store/drvs/ia.md) - [Input-Addressing](design/store/drvs/ia.md)
- [Content-Addressing (Experimental)](design/store/drvs/ca.md) - [Content-Addressing (Experimental)](design/store/drvs/ca.md)
- [Building](design/store/building.md) - [Building](design/store/building.md)
- [Advanced Topic: store object relocatability](design/store/relocatability.md) - [Advanced Topic: Store object relocatability](design/store/relocatability.md)
- [Advanced Topic: Related work](design/store/related-work.md)
- [Package Management](package-management/package-management.md) - [Package Management](package-management/package-management.md)
- [Basic Package Management](package-management/basic-package-mgmt.md) - [Basic Package Management](package-management/basic-package-mgmt.md)
- [Profiles](package-management/profiles.md) - [Profiles](package-management/profiles.md)

View file

@ -0,0 +1,37 @@
# Advanced Topic: Related Work
## Bazel
TODO skylark and layering.
TODO being monadic, if RFC 92.
## Build Systems à la Carte
TODO user-choosen keys vs keys chosen automatically?
Purity in face of dynamic tasks (no conflicts, guaranteed).
TODO Does Nix constitute a different way to be be monadic?
Purity of keys, as mentioned.
Dynamic tasks/keys vs dynamic dependencies.
(Not sure yet.)
## Lazy evaluation
We clearly have thunks that produce thunks, but less clearly functions that produce functions.
Do we have open terms?
Do we hve thunks vs expressions distinction?
c.f. John Shutt's modern fexprs, when the syntax can "leak".
## Machine models
TODO
Derivations as store objects via drv files makes Nix a "Von Neumann" archicture.
Can also imagine a "Harvard" archicture where derivations are stored separately?
Can we in general imagine N heaps for N different sorts of objects?
TODO
Also, leaning on the notion of "builtin builders" more, having multiple different sorts of user-defined builders too.
The builder is a black box as far as the Nix model is concerned.

View file

@ -1,5 +1,27 @@
# Nix Store
A Nix store is a collection of *store objects* referred to by *store paths*. A Nix store is a collection of *store objects* referred to by *store paths*.
Every store also has a "store directory path", which is a path prefix used for various purposes. Every store also has a "store directory path", which is a path prefix used for various purposes.
There are many types of stores, but all of them at least respect this model. There are many types of stores, but all of them at least respect this model.
Some however offer additional functionality. Some however offer additional functionality.
## A Rosetta stone for the Nix store.
The design of Nix is comparable to other build systems, even programming languages in general.
Here is a rough [Rosetta stone](https://en.m.wikipedia.org/wiki/Rosetta_Stone) for build system terminology.
If you are familiar with one of these columns, this might help the following sections make more sense.
generic build system | Nix | Bazel | Build Systems à la Carte | lazy programming language
-- | -- | -- | -- | --
data (build input, build result) | component | file (source, target) | value | value
build plan | derivation graph | action graph | `Tasks` | thunk
build step | derivation | rule | `Task` | thunk
build instructions | builder | (depends on action type) | `Task` | function
build | build | build | `Build` applied to arguments | evaluation
persistence layer | store | file system | `Store` | heap
(n.b. Bazel terms gotten from https://docs.bazel.build/versions/main/glossary.html.)
Plenty more could be said elaborating these comparisons.
We will save that for the end of this chapter, in the [Related Work](./related-work.md) section.