aboutsummaryrefslogtreecommitdiff
path: root/doc/manual/expressions/language-values.xml
diff options
context:
space:
mode:
Diffstat (limited to 'doc/manual/expressions/language-values.xml')
-rw-r--r--doc/manual/expressions/language-values.xml268
1 files changed, 268 insertions, 0 deletions
diff --git a/doc/manual/expressions/language-values.xml b/doc/manual/expressions/language-values.xml
new file mode 100644
index 000000000..519657f15
--- /dev/null
+++ b/doc/manual/expressions/language-values.xml
@@ -0,0 +1,268 @@
+<section xmlns="http://docbook.org/ns/docbook"
+ xmlns:xlink="http://www.w3.org/1999/xlink"
+ xmlns:xi="http://www.w3.org/2001/XInclude"
+ version="5.0"
+ xml:id='ssec-values'>
+
+<title>Values</title>
+
+
+<simplesect><title>Simple Values</title>
+
+<para>Nix has the following basic data types:
+
+<itemizedlist>
+
+ <listitem>
+
+ <para><emphasis>Strings</emphasis> can be written in three
+ ways.</para>
+
+ <para>The most common way is to enclose the string between double
+ quotes, e.g., <literal>"foo bar"</literal>. Strings can span
+ multiple lines. The special characters <literal>"</literal> and
+ <literal>\</literal> and the character sequence
+ <literal>${</literal> must be escaped by prefixing them with a
+ backslash (<literal>\</literal>). Newlines, carriage returns and
+ tabs can be written as <literal>\n</literal>,
+ <literal>\r</literal> and <literal>\t</literal>,
+ respectively.</para>
+
+ <para>You can include the result of an expression into a string by
+ enclosing it in
+ <literal>${<replaceable>...</replaceable>}</literal>, a feature
+ known as <emphasis>antiquotation</emphasis>. The enclosed
+ expression must evaluate to something that can be coerced into a
+ string (meaning that it must be a string, a path, or a
+ derivation). For instance, rather than writing
+
+<programlisting>
+"--with-freetype2-library=" + freetype + "/lib"</programlisting>
+
+ (where <varname>freetype</varname> is a derivation), you can
+ instead write the more natural
+
+<programlisting>
+"--with-freetype2-library=${freetype}/lib"</programlisting>
+
+ The latter is automatically translated to the former. A more
+ complicated example (from the Nix expression for <link
+ xlink:href='http://www.trolltech.com/products/qt'>Qt</link>):
+
+<programlisting>
+configureFlags = "
+ -system-zlib -system-libpng -system-libjpeg
+ ${if openglSupport then "-dlopen-opengl
+ -L${mesa}/lib -I${mesa}/include
+ -L${libXmu}/lib -I${libXmu}/include" else ""}
+ ${if threadSupport then "-thread" else "-no-thread"}
+";</programlisting>
+
+ Note that Nix expressions and strings can be arbitrarily nested;
+ in this case the outer string contains various antiquotations that
+ themselves contain strings (e.g., <literal>"-thread"</literal>),
+ some of which in turn contain expressions (e.g.,
+ <literal>${mesa}</literal>).</para>
+
+ <para>The second way to write string literals is as an
+ <emphasis>indented string</emphasis>, which is enclosed between
+ pairs of <emphasis>double single-quotes</emphasis>, like so:
+
+<programlisting>
+''
+ This is the first line.
+ This is the second line.
+ This is the third line.
+''</programlisting>
+
+ This kind of string literal intelligently strips indentation from
+ the start of each line. To be precise, it strips from each line a
+ number of spaces equal to the minimal indentation of the string as
+ a whole (disregarding the indentation of empty lines). For
+ instance, the first and second line are indented two space, while
+ the third line is indented four spaces. Thus, two spaces are
+ stripped from each line, so the resulting string is
+
+<programlisting>
+"This is the first line.\nThis is the second line.\n This is the third line.\n"</programlisting>
+
+ </para>
+
+ <para>Note that the whitespace and newline following the opening
+ <literal>''</literal> is ignored if there is no non-whitespace
+ text on the initial line.</para>
+
+ <para>Antiquotation
+ (<literal>${<replaceable>expr</replaceable>}</literal>) is
+ supported in indented strings.</para>
+
+ <para>Since <literal>${</literal> and <literal>''</literal> have
+ special meaning in indented strings, you need a way to quote them.
+ <literal>${</literal> can be escaped by prefixing it with
+ <literal>''</literal> (that is, two single quotes), i.e.,
+ <literal>''${</literal>. <literal>''</literal> can be escaped by
+ prefixing it with <literal>'</literal>, i.e.,
+ <literal>'''</literal>. Finally, linefeed, carriage-return and
+ tab characters can be written as <literal>''\n</literal>,
+ <literal>''\r</literal>, <literal>''\t</literal>.</para>
+
+ <para>Indented strings are primarily useful in that they allow
+ multi-line string literals to follow the indentation of the
+ enclosing Nix expression, and that less escaping is typically
+ necessary for strings representing languages such as shell scripts
+ and configuration files because <literal>''</literal> is much less
+ common than <literal>"</literal>. Example:
+
+<programlisting>
+stdenv.mkDerivation {
+ <replaceable>...</replaceable>
+ postInstall =
+ ''
+ mkdir $out/bin $out/etc
+ cp foo $out/bin
+ echo "Hello World" > $out/etc/foo.conf
+ ${if enableBar then "cp bar $out/bin" else ""}
+ '';
+ <replaceable>...</replaceable>
+}
+</programlisting>
+
+ </para>
+
+ <para>Finally, as a convenience, <emphasis>URIs</emphasis> as
+ defined in appendix B of <link
+ xlink:href='http://www.ietf.org/rfc/rfc2396.txt'>RFC 2396</link>
+ can be written <emphasis>as is</emphasis>, without quotes. For
+ instance, the string
+ <literal>"http://example.org/foo.tar.bz2"</literal>
+ can also be written as
+ <literal>http://example.org/foo.tar.bz2</literal>.</para>
+
+ </listitem>
+
+ <listitem><para><emphasis>Integers</emphasis>, e.g.,
+ <literal>123</literal>.</para></listitem>
+
+ <listitem><para><emphasis>Paths</emphasis>, e.g.,
+ <filename>/bin/sh</filename> or <filename>./builder.sh</filename>.
+ A path must contain at least one slash to be recognised as such; for
+ instance, <filename>builder.sh</filename> is not a
+ path<footnote><para>It's parsed as an expression that selects the
+ attribute <varname>sh</varname> from the variable
+ <varname>builder</varname>.</para></footnote>. If the file name is
+ relative, i.e., if it does not begin with a slash, it is made
+ absolute at parse time relative to the directory of the Nix
+ expression that contained it. For instance, if a Nix expression in
+ <filename>/foo/bar/bla.nix</filename> refers to
+ <filename>../xyzzy/fnord.nix</filename>, the absolute path is
+ <filename>/foo/xyzzy/fnord.nix</filename>.</para></listitem>
+
+ <listitem><para><emphasis>Booleans</emphasis> with values
+ <literal>true</literal> and
+ <literal>false</literal>.</para></listitem>
+
+ <listitem><para>The null value, denoted as
+ <literal>null</literal>.</para></listitem>
+
+</itemizedlist>
+
+</para>
+
+</simplesect>
+
+
+<simplesect><title>Lists</title>
+
+<para>Lists are formed by enclosing a whitespace-separated list of
+values between square brackets. For example,
+
+<programlisting>
+[ 123 ./foo.nix "abc" (f { x = y; }) ]</programlisting>
+
+defines a list of four elements, the last being the result of a call
+to the function <varname>f</varname>. Note that function calls have
+to be enclosed in parentheses. If they had been omitted, e.g.,
+
+<programlisting>
+[ 123 ./foo.nix "abc" f { x = y; } ]</programlisting>
+
+the result would be a list of five elements, the fourth one being a
+function and the fifth being a set.</para>
+
+</simplesect>
+
+
+<simplesect><title>Sets</title>
+
+<para>Sets are really the core of the language, since ultimately the
+Nix language is all about creating derivations, which are really just
+sets of attributes to be passed to build scripts.</para>
+
+<para>Sets are just a list of name/value pairs (called
+<emphasis>attributes</emphasis>) enclosed in curly brackets, where
+each value is an arbitrary expression terminated by a semicolon. For
+example:
+
+<programlisting>
+{ x = 123;
+ text = "Hello";
+ y = f { bla = 456; };
+}</programlisting>
+
+This defines a set with attributes named <varname>x</varname>,
+<varname>text</varname>, <varname>y</varname>. The order of the
+attributes is irrelevant. An attribute name may only occur
+once.</para>
+
+<para>Attributes can be selected from a set using the
+<literal>.</literal> operator. For instance,
+
+<programlisting>
+{ a = "Foo"; b = "Bar"; }.a</programlisting>
+
+evaluates to <literal>"Foo"</literal>. It is possible to provide a
+default value in an attribute selection using the
+<literal>or</literal> keyword. For example,
+
+<programlisting>
+{ a = "Foo"; b = "Bar"; }.c or "Xyzzy"</programlisting>
+
+will evaluate to <literal>"Xyzzy"</literal> because there is no
+<varname>c</varname> attribute in the set.</para>
+
+<para>You can use arbitrary double-quoted strings as attribute
+names:
+
+<programlisting>
+{ "foo ${bar}" = 123; "nix-1.0" = 456; }."foo ${bar}"
+</programlisting>
+
+This will evaluate to <literal>123</literal> (Assuming
+<literal>bar</literal> is antiquotable). In the case where an
+attribute name is just a single antiquotation, the quotes can be
+dropped:
+
+<programlisting>
+{ foo = 123; }.${bar} or 456 </programlisting>
+
+This will evaluate to <literal>123</literal> if
+<literal>bar</literal> evaluates to <literal>"foo"</literal> when
+coerced to a string and <literal>456</literal> otherwise (again
+assuming <literal>bar</literal> is antiquotable).</para>
+
+<para>In the special case where an attribute name inside of a set declaration
+evaluates to <literal>null</literal> (which is normally an error, as
+<literal>null</literal> is not antiquotable), that attribute is simply not
+added to the set:
+
+<programlisting>
+{ ${if foo then "bar" else null} = true; }</programlisting>
+
+This will evaluate to <literal>{}</literal> if <literal>foo</literal>
+evaluates to <literal>false</literal>.</para>
+
+
+</simplesect>
+
+
+</section> \ No newline at end of file