283 lines
		
	
	
	
		
			10 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
			
		
		
	
	
			283 lines
		
	
	
	
		
			10 KiB
		
	
	
	
		
			XML
		
	
	
	
	
	
<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>Numbers, which can be <emphasis>integers</emphasis> (like
 | 
						|
  <literal>123</literal>) or <emphasis>floating point</emphasis> (like
 | 
						|
  <literal>123.43</literal> or <literal>.27e13</literal>).</para>
 | 
						|
 | 
						|
  <para>Numbers are type-compatible: pure integer operations will always
 | 
						|
  return integers, whereas any operation involving at least one floating point
 | 
						|
  number will have a floating point number as a result.</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>
 | 
						|
 | 
						|
  <para>If the first component of a path is a <literal>~</literal>,
 | 
						|
  it is interpreted as if the rest of the path were relative to the
 | 
						|
  user's home directory. e.g. <filename>~/foo</filename> would be
 | 
						|
  equivalent to <filename>/home/edolstra/foo</filename> for a user
 | 
						|
  whose home directory is <filename>/home/edolstra</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>
 | 
						|
 | 
						|
<para>Note that lists are only lazy in values, and they are strict in length.
 | 
						|
</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>
 |