| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
in attribute set pattern matches. This allows defining a function
that takes *at least* the listed attributes, while ignoring
additional attributes. For instance,
{stdenv, fetchurl, fuse, ...}:
stdenv.mkDerivation {
...
};
defines a function that requires an attribute set that contains the
specified attributes but ignores others. The main advantage is that
we can then write in all-packages.nix
aefs = import ../bla/aefs pkgs;
instead of
aefs = import ../bla/aefs {
inherit stdenv fetchurl fuse;
};
This saves a lot of typing (not to mention not having to update
all-packages.nix with purely mechanical changes). It saves as much
typing as the "args: with args;" style, but has the advantage that
the function arguments are properly declared (not implicit in what
the body of the "with" uses).
|
|
f = args @ {x, y, z}: ...;
`args' refers to the argument as a whole, which is further
pattern-matched against the attribute set pattern {x, y, z}.
|
|
|
|
functions that take a single argument (plain lambdas) into one AST
node (Function) that contains a Pattern node describing the
arguments. Current patterns are single lazy arguments (VarPat) and
matching against an attribute set (AttrsPat).
This refactoring allows other kinds of patterns to be added easily,
such as Haskell-style @-patterns, or list pattern matching.
|
|
|
|
single quotes. Example (from NixOS):
job = ''
start on network-interfaces
start script
rm -f /var/run/opengl-driver
${if videoDriver == "nvidia"
then "ln -sf ${nvidiaDrivers} /var/run/opengl-driver"
else if cfg.driSupport
then "ln -sf ${mesa} /var/run/opengl-driver"
else ""
}
rm -f /var/log/slim.log
end script
'';
This style has two big advantages:
- \, ' and " aren't special, only '' and ${. So you get a lot less
escaping in shell scripts / configuration files in Nixpkgs/NixOS.
The delimiter '' is rare in scripts (and can usually be written as
""). ${ is also fairly rare.
Other delimiters such as <<...>>, {{...}} and <|...|> were also
considered but this one appears to have the fewest drawbacks
(thanks Martin).
- Indentation is intelligently stripped so that multi-line strings
can follow the nesting structure of the containing Nix
expression. E.g. in the example above 6 spaces are stripped from
the start of each line. This prevents unnecessary indentation in
generated files (which sometimes even breaks things).
See tests/lang/eval-okay-ind-string.nix for some examples.
|
|
|
|
bla'). Also allow trailing commas (`{x, y,}: ...') as a unintented
consequence. Hopefully the reduce/reduce conflict won't cause any
problems.
|
|
|
|
|
|
concatenation and string coercion. This was a big mess (see
e.g. NIX-67). Contexts are now folded into strings, so that they
don't cause evaluation errors when they're not expected. The
semantics of paths has been clarified (see nixexpr-ast.def).
toString() and coerceToString() have been merged.
Semantic change: paths are now copied to the store when they're in a
concatenation (and in most other situations - that's the
formalisation of the meaning of a path). So
"foo " + ./bla
evaluates to "foo /nix/store/hash...-bla", not "foo
/path/to/current-dir/bla". This prevents accidental impurities, and
is more consistent with the treatment of derivation outputs, e.g.,
`"foo " + bla' where `bla' is a derivation. (Here `bla' would be
replaced by the output path of `bla'.)
|
|
kind of notation for strings.
|
|
|
|
|
|
|
|
marshalling code.
|
|
* Optimise header file usage a bit.
* Compile the parser as C++.
|
|
argument has a valid value, i.e., is in a certain domain. E.g.,
{ foo : [true false]
, bar : ["a" "b" "c"]
}: ...
This previously could be done using assertions, but domain checks
will allow the buildfarm to automatically extract the configuration
space from functions.
|
|
|
|
"--with-freetype2-library=" + freetype + "/lib"
can now be written as
"--with-freetype2-library=${freetype}/lib"
An arbitrary expression can be enclosed within ${...}, not just
identifiers.
* Escaping in string literals: \n, \r, \t interpreted as in C, any
other character following \ is interpreted as-is.
* Newlines are now allowed in string literals.
|
|
on the Bison parse stack. Otherwise, a garbage collect during
parsing could lead to a crash.
|
|
|
|
[1 2 3] ++ [4 5 6] => [1 2 3 4 5 6]
|
|
|
|
|
|
Instead we generate data bindings (build and match functions) for
the constructors specified in `constructors.def'. In particular
this removes the conversions between AFuns and strings, and Nix
expression evaluation now seems 3 to 4 times faster.
|
|
|
|
The expression `with E1; E2' evaluates to E2 with all bindings in
the attribute set E1 substituted. E.g.,
with {x = 123;}; x
evaluates to 123. That is, the attribute set E1 is in scope in E2.
This is particularly useful when importing files containing lots
definitions. E.g., instead of
let {
inherit (import ./foo.nix) a b c d e f;
body = ... a ... f ...;
}
we can now say
with import ./foo.nix;
... a ... f ...
I.e., we don't have to say what variables should be brought into scope.
|
|
print a nice backtrace of the stack, rather than vomiting a gigantic
(and useless) aterm on the screen. Example:
error: while evaluating file `.../pkgs/system/test.nix':
while evaluating attribute `subversion' at `.../pkgs/system/all-packages-generic.nix', line 533:
while evaluating function at `.../pkgs/applications/version-management/subversion/default.nix', line 1:
assertion failed at `.../pkgs/applications/version-management/subversion/default.nix', line 13
Since the Nix expression language is lazy, the trace may be
misleading. The purpose is to provide a hint as to the location of
the problem.
|
|
`attrs ? x' yields true iff `attrs' has an attribute named `x'.
|
|
{stdenv, bash}: derivation {
builder = bash ~ /bin/sh;
args = ["-e" "-x" ./builder.sh];
...
}
Here the attribute `builder' will evaluate to, e.g.,
`/nix/store/1234abcd...-bash-2.0.1/bin/sh'.
|
|
`bla:' is now no longer parsed as a URL.
* Re-enabled support for the `args' attribute in derivations to
specify command line arguments to the builder, e.g.,
...
builder = /usr/bin/python;
args = ["-c" ./builder.py];
...
|
|
b then x else y.z'.
|
|
other attribute sets, rather than the current scope. E.g.,
{inherit (pkgs) gcc binutils;}
is equivalent to
{gcc = pkgs.gcc; binutils = pkgs.binutils;}
I am not so happy about the syntax.
|
|
{x=1; y=2; z=3;} // {y=4;} => {x=1; y=4; z=3;}
|
|
`inherit' variables from the surrounding lexical scope.
E.g.,
{stdenv, libfoo}: derivation {
builder = ./bla;
inherit stdenv libfoo;
xyzzy = 1;
}
is equivalent to
{stdenv, libfoo}: derivation {
builder = ./bla;
stdenv = stdenv;
libfoo = libfoo;
xyzzy = 1;
}
Note that for mutually recursive attribute set definitions (`rec
{...}'), this also works, that is, `rec {inherit x;}' is equivalent
to `let {fresh = x; body = rec {x = fresh;};}', *not*
`rec {x = x}'.
|
|
* Include missing files in distributions.
|
|
parser (roughly 80x faster).
The absolutely latest version of Bison (1.875c) is required for
reentrant GLR support, as well as a recent version of Flex (say,
2.5.31). Note that most Unix distributions ship with the
prehistoric Flex 2.5.4, which doesn't support reentrancy.
|
