remove incomplete section: related work

This commit is contained in:
Valentin Gagarin 2022-05-03 13:54:06 +02:00
parent 1ba6d8fb1d
commit 96876b1eae
2 changed files with 0 additions and 62 deletions

View file

@ -25,7 +25,6 @@
- [Input-Addressing](architecture/store/drvs/ia.md) - [Input-Addressing](architecture/store/drvs/ia.md)
- [Content-Addressing (Experimental)](architecture/store/drvs/ca.md) - [Content-Addressing (Experimental)](architecture/store/drvs/ca.md)
- [Advanced Topic: Store object relocatability](architecture/store/relocatability.md) - [Advanced Topic: Store object relocatability](architecture/store/relocatability.md)
- [Advanced Topic: Related work](architecture/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

@ -1,61 +0,0 @@
# 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".
## Comparison with Git file system model
This is close to Git's model, but with one crucial difference:
Git puts the "permission" info within the directory map's values instead of making it part of the file (blob, in it's parlance) object.
data GitObject
= Blob ByteString
| Tree (Map FileName (Persission, FSO))
data Persission
= Directory -- IFF paired with tree
-- Iff paired with blob, one of:
| RegFile
| ExecutableFile
| Symlink
So long as the root object is a directory, the representations are isomorphic.
There is no "wiggle room" the git way since whenever the permission info wouldn't matter (e.g. the child object being mapped to is a directory), the permission info must be a sentinel value.
However, if the root object is a blob, there is loss of fidelity.
Since the permission info is used to distinguish executable files, non-executable files, and symlinks, but there isn't a "parent" directory of the root to contain that info, these 3 cases cannot be distinguished.
Git's model matches Unix tradition, but Nix's model is more natural.
## 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.