NixOS/nix.dev
NixOS/nix.dev
1
0
Fork 0
mirror of https://github.com/NixOS/nix.dev.git synced 2024-10-18 14:32:43 -04:00
Code Activity

use "name" instead of "variable" consistently (#588)

Browse source 
strictly speaking, the Nix language does not have variables because what we call "variables" in the mathematical sense are names assigned to values that do not change, but can rather have different possible but fixed values depending on context.

this change is mainly to make use of words consistent with the Nix language tutorial in order to avoid any ambiguity and confusion for beginners, who may wonder why one article says "there are no variables" and the other one liberally uses the term regardless. always using "name" makes unmistakably clear that it's a variable in the mathematical sense.
This commit is contained in:
Valentin Gagarin 2023-06-13 21:45:42 +02:00 committed by GitHub
parent a094ffe818
commit 983ab67907
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
source/recipes/best-practices.md
View file

@ -14,7 +14,7 @@ Always quote URLs.
(rec-expression)=
## Recursive attribute set `rec { ... }`
`rec` allows you to reference variables within an attribute set.
`rec` allows you to reference names within the same attribute set.
Example:
@ -33,7 +33,7 @@ rec {
There are a couple of pitfalls:
- It's possible to introduce a hard to debug error `infinite recursion` when shadowing a variable, the simplest example being `rec { b = b; }`.
- It's possible to introduce a hard to debug error `infinite recursion` when shadowing a name, the simplest example being `let b = 1; a = rec { b = b; }; in a`.
- Combining with overriding logic such as the [`overrideAttrs`](https://nixos.org/manual/nixpkgs/stable/#sec-pkg-overrideAttrs) function in {term}`Nixpkgs` has a surprising behaviour of not overriding every reference.
:::{tip}
@ -68,8 +68,8 @@ This brings all attributes of the imported expression into scope of the current
There are a number of problems with that approach:
- Static analysis can't reason about the code, because it would have to actually evaluate this file to see which variables are in scope.
- As soon as there are two `with` used, it's not clear anymore where the variables are coming from.
- Static analysis can't reason about the code, because it would have to actually evaluate this file to see which names are in scope.
- When more than one `with` used, it's not clear anymore where the names are coming from.
- Scoping rules for `with` are not intuitive, see this [Nix issue for details](https://github.com/NixOS/nix/issues/490).
:::{tip}
@ -114,7 +114,7 @@ buildInputs = builtins.attrValues {
You will often encounter Nix language code samples that refer to `<nixpkgs>`.
`<...>` is special syntax that was [introduced in 2011] to conveniently access values from the shell environment variable [`$NIX_PATH`].
`<...>` is special syntax that was [introduced in 2011] to conveniently access values from the environment variable [`$NIX_PATH`].
[introduced in 2011]: https://github.com/NixOS/nix/commit/1ecc97b6bdb27e56d832ca48cdafd3dbb5185a04
[`$NIX_PATH`]: https://nixos.org/manual/nix/unstable/command-ref/env-common.html?highlight=nix_path#env-NIX_PATH