Literals
TracNav
Constant literal values of the primitive atomic types--boolean, long, double, string, undef, and null--may appear inside of a DML block. The following sections define the syntax for literal values of each type.
Boolean Literals
There are exactly two possible boolean values: true and false. They must appear as an unquoted word and completely in lowercase.
Long Literals
Long literals may be given in decimal, hexadecimal, or octal format. A decimal literal is a sequence of digits starting with a number other than zero. A hexadecimal literal starts with the '0x' or '0X' and is followed by a sequence of hexadecimal digits. An octal literal starts with a zero is followed by a sequence of octal digits. Examples:
123 # decimal long literal 0755 # octal long literal 0xFF # hexadecimal long literal
Long literals are represented internally as an 8-byte signed number. Long values that cannot be represented in 8 bytes will cause a syntax error to be thrown.
Double Literals
Double literals represent a floating point number. A double literal must start with a digit and must contain either a decimal point or an exponent. Examples:
0.01 3.14159 1e-8 1.3E10
Note that '.2' is not a valid double literal; this value must be written as '0.2'.
Double literals are represented internally as an 8-byte value. Double values that cannot be represented in 8 bytes will cause a syntax error to be thrown.
String Literals
The string literals can be expressed in three different forms. They can be of any length and can contain any character, including the NULL byte.
Single quoted strings are used to represent short and simple strings. They cannot span several lines and all the characters will appear verbatim in the string, except the doubled single quote which is used to represent a single quote inside the string. For instance:
’foo’ ’it’’s a sentence’ ’ˆ\d+\.\d+$’
This is the most efficient string representation and should be used when possible.
Double quoted strings are more flexible and use the backslash to represent escape sequences. For instance:
"foo" "it’s a sentence" "Java-style escapes: \t (tab) \r (carriage return) \n (newline)" "Hexadecimal escapes: \x3d (=) \x00 (NULL byte) \x0A (newline)" "Miscellaneous escapes: \" (double quote) \\ (backslash)" "this string spans two lines and\ does not contain a newline"
Invalid escape sequences will cause a syntax error to be thrown.
Multi-line strings can be represented using the 'here-doc' syntax, like in shell or Perl.
"test" = "foo" + <<EOT + "bar"; this code will assign to the path "test" the string made of ‘foo’, plus this text including the final newline, plus ‘bar’... EOT
The contents of the 'here-doc' are treated as a single-quoted string. That is, no escape processing is done.
The easiest solution to put binary data inside pan code is to base64 encode it and put it inside ”here- doc” strings like in the following example:
"/system/binary/stuff" = base64_decode(<<EOT); H4sIAOwLyDwAA02PQQ7DMAgE731FX9BT1f8QZ52iYhthEiW/r2SitCdmxCK0E3W8no+36n2G 8UbOrYYWGROCgurBe4JeCexI2ahgWF5rulaLtImkDxbucS0tcc3t5GXMAqeZnIYo+TvAmsL8 GGLobbUUX7pT+pxkXJc/5Bx5p0ki7Cgq5KccGrCR8PzruUfP2xfJgVqHCgEAAA== EOT
The base64_decode() function is one of the built-in pan functions.
Other Literals
undef
The undef literal can be used to represent the undefined element, i.e. an element which is neither a property nor a resource.
The undefined element cannot be written to a final machine profile and most built-in functions will report a fatal error when processing it. It can be used to mark an element that must be overwritten during the processing.
null
The null value deletes the path or global variable to which it is assigned. Most operations and functions will report an error if this value is processed directly.
