aboutsummaryrefslogtreecommitdiff
path: root/doc/manual/src/architecture/store/related-work.md
blob: 92b7d480ee2b86a7fc4c7a8674925575f31c82b3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
# 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.