aboutsummaryrefslogtreecommitdiff
path: root/doc/manual
diff options
context:
space:
mode:
Diffstat (limited to 'doc/manual')
-rw-r--r--doc/manual/src/SUMMARY.md.in1
-rw-r--r--doc/manual/src/architecture/store/related-work.md61
2 files changed, 0 insertions, 62 deletions
diff --git a/doc/manual/src/SUMMARY.md.in b/doc/manual/src/SUMMARY.md.in
index 596843057..ee7f5d7ac 100644
--- a/doc/manual/src/SUMMARY.md.in
+++ b/doc/manual/src/SUMMARY.md.in
@@ -25,7 +25,6 @@
- [Input-Addressing](architecture/store/drvs/ia.md)
- [Content-Addressing (Experimental)](architecture/store/drvs/ca.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)
- [Basic Package Management](package-management/basic-package-mgmt.md)
- [Profiles](package-management/profiles.md)
diff --git a/doc/manual/src/architecture/store/related-work.md b/doc/manual/src/architecture/store/related-work.md
deleted file mode 100644
index 92b7d480e..000000000
--- a/doc/manual/src/architecture/store/related-work.md
+++ /dev/null
@@ -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.