In a <ref dlay>Zonk datafile</r> the same variable name may appear more than once and on each occasion it may be given a different value. A variable that has multiple values like this I refer to as 'dynamic'. To put it another way, it has a list of values and at any time one of these will be its 'current' value.
If a variable has only one value then it <i>may</i> be 'static'. Note though, that unless you do something in the template that forces it to be one or the other, it can be either.
It is important to understand the difference between static and dynamic variables if you use multipage datafiles, as dynamic variables are discarded at the end of each page whereas static variables are not. It is also important therefore to 'force' a variable which could be either, but whose value you wish to keep over page breaks, <ref ctagv#stat>to be static</r>.
<sh>Variable name modifiers</sh>
Unless otherwise stated, whenever I indicate that the syntax allows you to use a <var>variablename</var>, then it is possible to prefix the name with a single character 'source modifier' and append onto the name a single character 'treatas' modifier. No whitespace is allowed between these items.
<b>Source modifier</b>: Normally Zonk checks for a variable firstly in the user data table, if it is not found there it moves on to the global table (if supplied) and finally the system table if needed. Thus a user can override the settings of variables from the system and global files. However putting a source modifier in front of the name forces the use of a particular file's definiton:
<ul>
'*' - forces the use of the system file
'!' - forces the use of the global file
</ul>
There are also the following characters which, although not really source modifiers, appear in the same position and therefore do not allow a genuine source modifier to be used.
<ul>
'^' - to refer to a temporary variable created with <ref cmakt><zonk maketag></r>.
'%' - to refer to an <ref intvar>internal variable</r>.
</ul>
<b>treatas</b>: Variable values in zonk are by default treated as strings. But when a <lit>format</lit> string is used (see <ref ctagv>tagvalue</r> and <ref cmakt>maketag</r>) you may want to interpret the value differently. The available modifiers are:
<ul>
'#' - forces an integer interpretation of the leading part of the variable's value string
'~' - forces a floating point interpretation of the leading part of the variable's value string
'@' - forces a date interpretation of the whole of the variable's value string
</ul>
<sh>Expressions</sh>
where you see <var>expression</var> in a syntax it can be any of:
and must have at least one whitespace character in front of it.
Variables inside bracketed expressions are always treated as integers, outside of brackets, you need to add the appropriate 'treatas' modifier. Bracketed expressions with the arithmetic operators (and integer constants) always return an integer value. Bracketed logicial expressions return the string "1" for a logically true expression. For a logically false expression it returns the NULL value. This may not make much sense here but it does in the context of <ref cif>zonk if</r> and <ref cwhil>zonk while</r> which is where logical expressions are really intended to be used.
</ul>
You may see from the above definition that <var>expression</var> is recursive, that is bracketed expressions can themselves contain bracketed expressions and so on. There is no theoretical limit to the level of nesting other than that imposed by the program's memory. Also note that a bracketed expression has no optional parts, it must always consist of two other expressions and an operator. You cannot therefore have (1 + 2 + 3) but you can have ((1 + 2) + 3)
<sh>Template command format</sh>
Within a template the general format of a Zonk command is:
as with html in general there should be no whitespace between the opening '<' and the word 'zonk' or the command will not be recognised. It is worth mentioning here that zonk commands inside html comments ( <!-- --> ) are still processed, so if you want to comment out a zonk command do something like
<lit><-zonk <var>commandname</var>></lit>
There is also a special class of Zonk commands (the <ref pulo>$pullout</r> family) which appear like html comments themselves, that is:
since unlike normal Zonk commands, they remain in the output html. All is explained in more detail in the relevant sections.
Note that the Zonk parser is not case sensitive and that whitespace characters (return, space, tab etc) usually have no significance. Where whitespace is significant it will be noted in the descriptions which follow.
<sh>Header line</sh>
To help prevent a raft of misleading error messages should you accidentally give as input to the program a file which is not intended for Zonk, every Zonk input file, whether it be a datafile, a configuration file or a template, needs to have an identifying header line which <i>must</i> be the first line of the file.
The header line consists of:
<lit>$zonkpage <var>minimum program version</var></lit>
Where <var>minimum program version</var> identifies the earliest version of Zonk which can correctly interpret this file. So, for any files you create for use with this version the header line should be:
<lit>$zonkpage 1.07</lit> (don't include the 'b')
It is my intention that although later versions of the program may extend the format of any of the input files in some way, new versions will always be backwards compatible with already existing files.
