* Numbers can have suffixes to specify standard multipliers:
+ `[kKmMgG]` - standard 10 base multipliers (so `1k` is translated to 1000)
+ `[kKmMgG]b` - 2 power multipliers (so `1kb` is translated to 1024)
+ `[s|min|d|w|y]` - time multipliers, all time values are translated to float number of seconds, for example `10min` is translated to 600.0 and `10ms` is translated to 0.01
* Hexadecimal integers can be used by `0x` prefix, for example `key = 0xff`. However, floating point values can use decimal base only.
* Booleans can be specified as `true` or `yes` or `on` and `false` or `no` or `off`.
* It is still possible to treat numbers and booleans as strings by enclosing them in double quotes.
## General improvements
### Commments
UCL supports different style of comments:
* single line: `#`
* multiline: `/* ... */`
Multiline comments may be nested:
```c
# Sample single line comment
/*
some comment
/* nested comment */
end of comment
*/
```
### Macros support
UCL supports external macros both multiline and single line ones:
*`duplicate` (default: 'append') - specify policy of duplicates resolving:
-`append` - default strategy, if we have new object of higher priority then it replaces old one, if we have new object with less priority it is ignored completely, and if we have two duplicate objects with the same priority then we have a multi-value key (implicit array)
-`merge` - if we have object or array, then new keys are merged inside, if we have a plain object then an implicit array is formed (regardeless of priorities)
-`error` - create error on duplicate keys and stop parsing
-`rewrite` - always rewrite an old value with new one (ignoring priorities)
UCL supports variables in input. Variables are registered by a user of the UCL parser and can be presented in the following forms:
*`${VARIABLE}`
*`$VARIABLE`
UCL currently does not support nested variables. To escape variables one could use double dollar signs:
*`$${VARIABLE}` is converted to `${VARIABLE}`
*`$$VARIABLE` is converted to `$VARIABLE`
However, if no valid variables are found in a string, no expansion will be performed (and `$$` thus remains unchanged). This may be a subject
to change in future libucl releases.
### Multiline strings
UCL can handle multiline strings as well as single line ones. It uses shell/perl like notation for such objects:
```
key = <<EOD
some text
splitted to
lines
EOD
```
In this example `key` will be interpreted as the following string: `some text\nsplitted to\nlines`.
Here are some rules for this syntax:
* Multiline terminator must start just after `<<` symbols and it must consist of capital letters only (e.g. `<<eof` or `<< EOF` won't work);
* Terminator must end with a single newline character (and no spaces are allowed between terminator and newline character);
* To finish multiline string you need to include a terminator string just after newline and followed by a newline (no spaces or other characters are allowed as well);
* The initial and the final newlines are not inserted to the resulting string, but you can still specify newlines at the begin and at the end of a value, for example:
```
key <<EOD
some
text
EOD
```
## Emitter
Each UCL object can be serialized to one of the three supported formats:
UCL allows validation of objects. It uses the same schema that is used for json: [json schema v4](http://json-schema.org). UCL supports the full set of json schema with the exception of remote references. This feature is unlikely useful for configuration objects. Of course, a schema definition can be in UCL format instead of JSON that simplifies schemas writing. Moreover, since UCL supports multiple values for keys in an object it is possible to specify generic integer constraints `maxValues` and `minValues` to define the limits of values count in a single key. UCL currently is not absolutely strict about validation schemas themselves, therefore UCL users should supply valid schemas (as it is defined in json-schema draft v4) to ensure that the input objects are validated properly.
