From 96876b1eaeae95e3f2f338c6b3495040fc843c57 Mon Sep 17 00:00:00 2001 From: Valentin Gagarin Date: Tue, 3 May 2022 13:54:06 +0200 Subject: [PATCH] remove incomplete section: related work --- doc/manual/src/SUMMARY.md.in | 1 - .../src/architecture/store/related-work.md | 61 ------------------- 2 files changed, 62 deletions(-) delete mode 100644 doc/manual/src/architecture/store/related-work.md 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.