Zz: THE TAO ENGINE

The Zz variables are dynamic; they are created when assigning values to them. A Zz variable has a value and a tag. The tag of the Zz variables is the type of the expression assigned to it. There is a correspondence between lexical tokens and tags.

The assignment statement has the following formats:

or

The optional type is some kind of tag used by a Zz expert to change the tag of expression. It can be any syntagma, as we'll explain in the following.

The assignment form ":=" creates GLOBAL VARIABLES which remain alive until the EOF is reached, while the "=" one creates LOCAL VARIABLES, which remain alive until the EOF (if declared at level 0) or local block's closing brace "}" (if declared within a block) is reached. How to use these variables will be explained later.

Zz language offers some facilities to manage the lists. A sequence of tokens within braces {} is interpreted as a list. It is possible to explicitly assign a list to a variable using the following format:

Wherein any token is allowed with the exception of "}" and an unmatched double quote ". List tokens are delimited by spaces.

As example of assignment to a variable:

zz> /my_list = { alfa b c , "anymore" 23.4 }"}

It is possible to refer to any item of a list using the notation variable.item_number, where item_number is the 1 based index number of the item we want to refer to. It is also possible to print the length of the list (i.e. the number of the elements in the list) using the notation variable.length.

As an example, using the list defined above:

zz> /print my_list.1 , my_list.4
alfa ,
zz> /print my_list.length
6
zz>

The four usual arithmetic operations (*, /, +, -) are supported for integer and floating point data types, following the usual rules of precedence. The type of the result is chosen depending on the type of the operands with the usual rules of floating type conversion for mixed floating/integer calculations.

A concatenation operator "&" is defined. The "&" symbol can be used to join identifiers, strings, or lists, and it can also operate if one of the operands is a numeric variable. In this case it takes the corresponding literal value of the number.

Examples:

zz> /id = "blabla" 
zz> /golf = id & 12*(4+5) 
zz> /print golf 
blabla108 
zz> 
zz> /v1=15 
zz> /v2=16 
zz> /id = ciccio &_& v1 &_& v2 
zz> /print id 
ciccio_15_16 
zz> /my_list = { 123 "mouse" 2.4 } 
zz> /print my_list 
{ 123 mouse 2.4 } 
zz> /print my_list.2 
mouse 
zz> /new_list = my_list & { 123 } 
zz> /print new_list 
{ 123 mouse 2.4 123}

When ZZ doesn't recognize a statement it prints a diagnostic message.

Example:

zz> /alfa=12*(13 # 40)
+ **** SYNTAX ERROR ****
| got: '#'
| expected one of:  '*' '/' ')' '+' '-'
| /alfa=12*(13 # 40)
|              ^
| line 1 of stdin
zz>

The unexpected token is underlined by a "^" sign. Zz also prints the pertinent rules, underlining the place where the mismatch occurred.

In the previous example the following character are acceptable: *, /, ), +, -, while # is meaningless.

The key power of ZZ is the capability of expanding the recognized language. To add syntax extension to ZzL0 it is necessary to specify something on which to match, and an action to execute when this match occurs.

Now we introduce a new statement (shortly: stat) to display the Zz version. This new statement will be: "show version":

zz> /stat -> show version { 
.. /print "Zz Version 2.0 31, October 1991\n" 
.. } 
zz> 
zz> show version 
Zz Version 2.0 31, October 1991

The usual prompt "zz>" changes to a couple of dots to show that the action specification has to be completed. It is possible to overload a part of the above statement to display something else:

zz> /stat -> show authors { 
.. /print "Zz's authors are:" 
.. /print " Simone Cabasino" 
.. /print " Pier Stanislao Paolucci" 
.. /print " Gian Marco Todesco" 
.. } 
zz> show authors 
Zz's authors are: 
Simone Cabasino 
Pier Stanislao Paolucci 
Gian Marco Todesco 
zz> show version 
Zz Version 2.0 31, October 1991

In the examples just shown we added new syntaxes to the grammar of the statements (stat), writing:

zz> /stat -> thread { actions }

We call these kinds of statements "syntax extensions". More generally the form of the syntax extension statement is:

"stat" is a good syntagma. Actually stat is the only syntagma that we have seen up to now: we will describe general syntagmas later.

We call "thread" the pattern (or rule) we are adding to the syntax (more exactly to the syntagma) and that Zz will be able to recognize when met. We call "action" the list of Zz statements, within braces {}, to be executed when the thread will be matched. The action is an optional field.

A thread is a list of beads. There are terminal beads like show, author, authors or Hello and nonterminal beads. Nonterminal beads will be introduced later.

Let's try with an error:

zz> show author 
***** SYNTAX ERROR 
etc.... 

We can foresee this error and give a friendlier message:

zz> /stat -> show author { 
.. /print "There are several authors of Zz."
.. /print "The correct statement is 'show authors'" 
.. /print "anyway:" 
.. show authors 
.. } 
zz> 
zz> show author 
There are several authors of Zz.
The correct statement is 'show authors'
anyway: 
Zz's authors are:
Simone Cabasino 
Pier Stanislao Paolucci 
Gian Marco Todesco

Please note that you can use the stat "show authors" within the action of "show author".

The statement /rules shows all the syntax rules added to Zz:

zz> /rules 
RULES
 Scope kernel 
  stat -> show author
  stat -> show authors
  stat -> show version
  stat -> say Hello

Here follows a set of examples to summarize:

zz> /stat -> "?" { 
.. /print "Commands today are:" 
.. /print " say Hello" 
.. /print " show version" 
.. /print " show authors" 
.. } 
zz> 
zz> /stat -> 12 { 
.. /print "you typed the integer number 12" 
.. } 
zz> 
zz> /stat -> 12.0 {
.. /print "you typed the fp number 12.0" 
.. } 
zz> 
zz> 12 
you typed the integer number 12 
zz> 
zz> 000012 
you typed the integer number 12 
zz> 
zz> 12.000000 
you typed the fp number 12.0 
zz> 
zz> 12. 
you typed the fp number 12.0 
zz> 
zz> 1.2e1 
you typed the fp number 12.0

Let's again introduce a syntax extension with an example (that we strongly suggest to try) of a nonterminal bead in the thread:

zz> /stat -> "I am " ident^name { 
.. /print "Hello ",name, "!" 
.. } 
zz> 
zz> I am freddy 
Hello freddy!

Of course an integer number is not a legal identifier and Zz will warn us about it:

zz> I am 13 
***** SYNTAX ERROR etc....

In the example above the nonterminal bead is ident^name. Here, "name" is like a variable and identifies the bead inside the thread. "ident" is predefined, it will match any legal identifier.

The general form of a nonterminal bead is:

A nonterminal bead is made up of the syntagma, the character ^ (caret), and an identifier that plays the role of a formal parameter and can be used like a variable within the action. A nonterminal bead matches a set of syntactical objects (eg: identifiers and integers but also expressions or programs as we'll show in the following). We use "syntagma" for the name of those sets.

ident, stat and int are good examples of predefined syntagmas built in the kernel of Zz, and hence always available. We'll see in the following that when the action is executed (because the thread has matched something) all the formal parameters will have the actual value just matched.

We can create new syntagmas simply by using it in a nonterminal bead or assigning to it a thread with the syntax extension statement. This means that it is possible to assign one or more threads to a syntagma by using it in a following statement or refer (within a nonterminal bead) to a syntagma, which has not yet any thread assigned to it. It is possible to say informally that a syntagma is a collection of threads and a syntax extension is the way to assign a new thread (with the corresponding action) to a syntagma. When the parser has to match a nonterminal bead it tries to match all the threads of the syntagma referenced in the nonterminal bead.

A new syntagma: color is defined in the following example:

zz> /stat -> use the ink color^c { 
.. /print " I'm using the color n.",c
.. }
zz> 
zz> /color -> red { /return 1 } 
zz> /color -> violet { /return 2 } 
zz> /color -> pink { /return 3 } 
zz> 
zz> 
zz> use the ink red 
I'm using the color n.1

We have seen above the practical usage of the statement /return. The statement /return makes sense only within actions because it is used to give a value to the formal parameter of a nonterminal bead. It is possible to return something changing its type in a way like the assignment does. The general form of the return statements is:

Using a syntagma with no thread associated to it generates a syntax error. Try this kind of error with the undefined color yellow:

zz> use the ink yellow 
***** SYNTAX ERROR 
etc.... 

The following example, that we again suggest to try, shows an interesting concept:

zz> /color -> gray int^a "%" {/return 100+a} 
zz> use the ink gray 20% 
I'm using the color n. 120 

As you can see the new color just defined is more complex then a simple token. When in action we are not interested in the actual parameter's values, like in the following example:

zz> /stat -> "I'm" ident^name {/print "Hello!"} 

We can use as a convention the name "$" for the formal parameter:

zz> /stat -> "I'm" ident^$ {/print "Hello!"} 

When we use the $ sign in formal parameters we remark that the parameter is dummy, but it is a mere convention. In fact the $ is treated by Zz as any other identifier.

In a rule like this:

zz> /stat -> "I'm" ident^$ "from" ident^$ { 
/print "Hello!" 
} 

The value of $ is replaced twice during the parsing, i.e.

zz> I'm Laura from Rome 
Hello! 

When the thread is parsed the identifier "Laura" and then "Rome" are associated to the parameter $. When the action is executed the $ parameter contains the last value "Rome", in fact:

zz> /stat -> "I'm" ident^$ "from" ident^$ { 
/print "Hello!' 
/print $ 
} 
zz> I'm Laura from Rome 
Hello! 
Rome 

And the same behavior occurs if $ is substituted by another identifier.

Sometimes it could be useful to control the parsing flow. It will be possible to iterate the parsing (something like a loop) and to conditionally parse some sentence (something like a conditional branch).

In the current version of Zz, the following are implemented: /for, /foreach, /do, /while, /if.

There are some utilities to handle syntax extensions. The statements:

/krules [syntagma ] 
/rules [syntagma ] 

These are used to print both kernel and user threads (/krules) or only user rules (/rules). The optional syntagma is used to print only the rules attached to a specific syntagma.

There is a statement to show all the variables active at a certain level:

/param 

This statement can be used within an action to know the parameter's values.

We introduce with this example the concept of overloading:

zz> /stat -> show int^x { 
.. /print "Integer ",x 
.. } 
zz> 
zz> /stat -> show float^x { 
.. /print "Floating Point ",x 
.. } 
zz> 
zz> show 12 
Integer 12 
zz> 
zz> show 12.0 
Floating Point 12.0000 

In the example above the word show manifests two different behaviors depending only on the type of the number (12 or 12.0). In other words the statement show is overloaded. The parser is able to resolve the overloading ambiguity choosing the right thread according to the type of the nonterminal beads: int^x or float^x. There are other languages allowing some kind of overloading: ADA and C++ for instance allow the operator overloading, but not the definition of new operators.

In the following example we show how ZzL0 variables dynamically change their type:

zz> /my_value = 12 !! my_value is integer 
zz> show my_value 
Integer 12 
zz> /my_value = 12.0 !! my_value now is float 
zz> show my_value 
Floating Point 12.000000

We prefer the typographic style described below.

When the action is very short or omitted all the SE has to be written on only one line:

zz> /stat -> one_hello { /print "Hello, World!" } 
zz> /stat -> this is an unuseful statement and... 
does nothing 

Elsewhere we prefer to begin at new line the action:

zz> /stat -> four_hello { 
.. one_hello 
.. one_hello 
.. one_hello 
.. one_hello 
.. } 
zz> 

It is forbidden to insert a new line before the open brace.

Examples

zz> /color -> green { /return 10 } 
zz> /color -> blue { /return 20 } 
zz> /stat -> the ink is color^c {/print "ink = ",c} 
zz> 
zz> /feeling -> glad { /return 1000 } 
zz> /feeling -> blue { /return 1001 } 
zz> 
zz> /stat -> I feel feeling^f {/print "You feel ",f} 
zz> 
zz> I feel blue 
You feel 1001 
zz> 
zz> the ink is blue 
ink = 20 
zz> 
zz> /arg3 -> int^a "," int^b "," int^c { 
.. /print "push ",a 
.. /print "push ",b 
.. /print "push ",c 
.. } 
zz> /stat -> goofie arg3^$ { 
.. /print "call goofie" 
.. } 
zz> pippo 1,2,3 
push 1 
push 2 
push 3 
call pippo

The infix operators' notation is user friendly but potentially ambiguous. Thus there are two options to compute the expression 2 + 3 + 4:

This ambiguity is of course often negligible, but can be dangerous if the operator isn't associative: (2/3)/4 != 2/(3/4).

Let's imagine a translator which converts infix (ambiguous) operators into RPN notation (that is unambiguous). We define explicitly an unambiguous grammar (left associative):

zz> /stat -> expr^e 
zz> /expr -> fact^$ 
zz> /expr -> expr^$ "/" fact^$ {/print "divide"} 
zz> /fact -> int^n {/print "push ",n}

This is to test the example:

zz> 20/10/5 
push 20 
push 10 
divide 
push 5 
divide 

Of course it is possible to change one line to change the associativity:

zz> /stat -> expr^e 
zz> /expr -> fact^$ 
zz> /expr -> fact^$ "/" expr^$ {/print "divide""} 
zz> /fact -> int^n {/print "push ",n} 

and now:

zz> 20/10/5 
push 20 
push 10 
push 5 
divide 
divide

When the action is defined all the parameters (associated to the nonterminal beads) and variables within the braces {} are evaluated and the name is replaced with the corresponding value. Local variables (assigned with =) are replaced immediately (when the action is declared) while the other kind (assigned with :=) is replaced only when the action is executed (see also Using Zz variables).

We have seen up to this point only Zz action within braces {}, but there are two other kinds of actions, thus the syntax extension statement has three different formats:

The first format is well known. The second one is used to call a user C procedure (UCP) linked with the Zz kernel, optionally passing to it its parameters (see Part III). The third one is used to return a constant value; this format is very similar to:

The third format is fastest because Zz doesn't have to interpret the action; however no variable replacement will occur.

The kernel makes available a simple C-Procedure: pass that is used to return all the parameters of nonterminal beads in the thread. Thus the following examples (a) and (b) are equivalent but the second one is faster:

The following form:

zz> /sss -> ... xxx^yyy ... :return yyy

is wrong because yyy is not a constant expression, in this case Zz will every time return "yyy" and not its actual value.

zz> /stat -> show names^x {/print " phone: ", x } 
zz> /stat -> show any^${/print "phone not available" } 
zz> 
zz> /names -> paola { /return "0034345678" } 
zz> /names -> tony  { /return "002143545" } 
zz> /names -> albert{ /return "home:123456 office:3445" } 
zz> 
zz> show albert 
phone: home:123456 office:3445 
zz> show carin 
phone not available 

zz> /stat -> add ident^n qstring^p... 
{/names> n { /return p } } 
zz> add luisa "off. 35682"
zz> show luisa 
phone: off. 35682 

zz> add luisa "off. 3935682"
zz> show luisa 
phone: off: 3935682 

zz> /int_decl -> ident^name "[" int^size "]" { 
.. /return { name size } !! unidim. array 
.. } 
zz> 
zz> /int_decl -> ident^name { 
.. /return { name 1 } !! scalar var 
.. } 

We have already seen that the format := creates GLOBAL VARIABLES which remain alive until the EOF is reached, while the = one creates LOCAL VARIABLES which remain alive until the EOF (if declared at level 0) or the matching brace "}" (if declared within a block) are reached.

Variables declared within a block become alive when the block is parsed (executed). These variables can be used in the definition of other blocks inside the one which is currently parsed: these blocks, that are not executed now, will be called "inner blocks".

There is a major difference between the use of a variable within the block in which it is declared and its use in an inner block.

There are three kinds of variables: Zz variables, Zz parameters, and thread variables. Of course if you are using Zz to develop a compiler you have to consider also the variables of your language, but for now let's ignore them.

We have already talked about Zz variables.

The Zz parameters are implicitly declared using a nonterminal bead within a thread:

A parameter hides any identically named variable and its scope is the action attached to the thread. Pay attention because if param is a variable the value of that variable replaces the parameter itself in the thread:

zz> /c = alfa
zz> /stat -> say ident^c { !!we are entering a new block
.. /print alfa !!the param c is replaced by
.. } !!alfa in the thread
zz> say hello
hello
zz> /rules
RULES
 Scope kernel
  stat -> echo
  stat -> say ident^alfa
  stat -> echo^s

zz> /c=12 
zz> /stat -> say ident^c {/print c} 
*** SYNTAX ERROR ***... 

The third kind of variable (thread variable) is made up in the following way:

zz> /$arg -> alfa : return 154 
zz> /print alfa 
154

$arg is a predefined syntagma used in all the expression to match the arguments; if a new thread (say: alfa) is assigned to it when it matches (say met alfa) the returned value of $arg is the value returned by the action (here: 154). This kind of variables are global, of course it is possible to introduce a friendly interface to declare them:

zz> /stat -> let ident^name "=" int^val { 
.. /$arg -> name {/return val } 
.. } 
zz> let goofie = 3 !!goofie is now a global $arg 
zz> /print goofie 
3 

Syntax Extensions are organized in levels. All the levels have a name and they are organized in a stack. New rules are inserted by default in the current level, the top of the stack at startup. There default scope (level) is called the "kernel" scope.

A new scope is created by typing:

At this point scope_name is the current scope at the top of the stack and all the new rules inserted from now on will be assigned by default to this scope.

The current scope can be removed from the stack typing:

The scope is not lost. It is only inactive and it can be restored typing again

To delete a scope it is necessary to type:

All the rules that belong to that scope are lost. To insert a rule in a scope which is not the current top of stack the following syntax should be used:

The stack implies a hierarchy among the scopes. The parser in fact attempts to reduce a rule in the topmost level and, failing that, in the deeper active levels (inactive levels are not considered). If a rule is found at a certain level the parser ignores deeper levels. Within the same level Zz is not able to resolve an ambiguity. Newly created rules can hide rules in deeper levels, meaning that among rules with the same thread but different actions Zz will reduce the rule in the shallowest level.

If there are rules declared within scope_name with the clause /when delete scope the specified actions are executed (see in the following).

It is also possible to empty a scope using the following syntax:

That will delete and repush the scope scope_name.

It is possible to specify an action to be executed when the action associated to a thread is modified. The syntax is the following:

Please note that the simplest statement to change a syntax is:

But usually the user introduces some statement to modify automatically the syntax: of course at some deepest level the statement is the simplest one.

The action action_a is executed if the action_b associated to the rule /syntagma -> thread is changed.

This version of Zz uses 4bytes for representing integer and float. This creates a little problem when passing float, because C compilers cast to double the float arguments. So if you write a C-Procedure with some float argument this will go wrong. A similar problem arises for the returned value.

The solution up to now is to declare the C-Procedure as returning and/or accepting long integer and converting the values into/from float inside the procedure using the following trick:

gasp(ix) 
long ix; 
{ 
  float x,y; 
  long iy; 
  x = *(float*) 
  .... 
  iy= *(long int*) 
  return iy; 
} 

Get the name of the current file (for interactive session return 'stdin').

Get the name of the current source (for interactive session return 'stdin').

Get current line number.

Write the current line with an arrow marking the current position and write down the current line number, the current file and so forth.

Before invoke Zz your application as to call kernel(), this routine initializes the environment that Zz need. The Zz routine has following prototype:

void zz(char* file_in,char* file_ext,char* file_out);

It is possible to use default values (if the parameter is zero): default file_in is stdin, default file_out is stdout, default file_ext is ".zz".

Example:

main() 
{
  kernel(); 
  zz(0,0,0); /* uses all defaults */ 
}

The SCP mechanism is quite naive: the user has to write a file (say sua.zz) with the ANSI standard prototype of his functions and subroutines, like in the following example:

/include "hzlib:decl.hz"
begin 
  int fopen( char * file_spec, char *a_mode); 
  void fputs ( char *buffer, int file_ptr); 
end

Zz is able to read this file and produces a C source file. The command can be the following:

$ zz +C sua.zz sua.c 

The file "sua.c" will contain the description of the syntax to invoke the user procedures and the appropriate calls. This file has to be linked with the Zz kernel and with the file[s] containing the user C procedures (the example doesn't require anything more because fopen and fputs are in the standard C libraries). The resulting executable program will be a configured version of Zz including the Soft user C-Procedures.

The double exclamation mark, !!, is interpreted by the lexical analyzer like an EOL. All the characters following this symbol until the true EOL are ignored.

Three contiguous dots: ... are interpreted like a "line continues" marker. It means that the line has to be completed with the following line. All the characters to the EOL are ignored.

The lexical analyzer ignores all redundant spacing. Space and/or tabs are significant only to separate identifiers and numbers. It should be noted that special characters are always to be considered different tokens.

Examples:

Input stream tokens [tag, value]

"+hiA"A++ [qstring,+hiA][ident,A][char,+][char,+]
"+h i A" A+ [qstring,+h i A] [ident,A] [char,+]
+hi B 3 [char,+] [ident,hi] [ident,B] [int,3]
+hiB3 [char,+] [ident,hiB3]

When the input stream is an ANSI TTY the user benefits of an interactive shell with some editing capabilities: the keypad arrows are available to select old commands or to edit a command.

There are some implicit precedence rules that the user cannot control. The parser uses the following order of precedence to accept a token:

When beads are in competition to match a token the parser chooses immediately based on the precedence of the tag. E.G. If a token is either a legal identifier or a keyword the parser will match it as a keyword.

Zz starts and recognizes a basic language called Zz language level 0 or simply Zz L0. By means of syntax extensions this language can evolve.

The character: ";" (semi colon) at the end of the statement is necessary to put two or more statements on the same line.

All the Zz L0 statements are prefixed with the character "/", this symbol can be useful to distinguish added statements from the original ones. The user can however introduce statements prefixed with the same slash: "/".

Probably the most important statements of Zz L0 are the ones to increment or modify the syntax. They are described in a separate chapter.

As written above, there are two kinds of beads: simple (or terminal) beads and non terminal beads.

The behavior of the parser is the following:

A simple bead can be an identifier, integer number, a floating point number and a quoted string.

The first bead matches only the identifier HALLO the second bead will match the integer number 666 (as well as 00666), the third bead will match the floating number 3.1415 (as well as 03.14150 or 31415e4), the fourth one will match the sequence of token ABC > 22 + C (no matter of care of the spacing). Indeed the bead "ABC > 22+C" is totally equivalent to the sequence of beads: ABC ">" 22 "+" C.

A non terminal bead is used to match a syntactical construct (syntagma). The format (within a thread) to insert a non terminal bead is:

There are two kinds of syntagmas (and corresponding two types of beads): lexical syntagmas and derived syntagmas.

The lexical beads are:

These beads match the tokens with corresponding tag and by convention return in the parameter the corresponding value (returned by the lexical analyzer). The first bead will match well formed identifiers, the second one string within double quote: " ", the same for float and int. There are special situations when it is useful that the parser accepts any token; the special bead useful in this case is any^. It is possible to attach new rules to a lexical syntagma.

It is important to underline that Zz in order to handle variable and parameters has to identify as soon as possible identifier that are defined as Zz variables, thus the syntagma param matches only identifier having a value and it returns the name of the variable.

The derived beads are a directive for the parser to match the rules corresponding to the related syntagma.

Example:

To be effective some rules of this kind will be defined to give a meaning to syntagma_x:

Example:

/syntagma_x -> thread_a {action_a; /return xxxx} 
/syntagma_x -> thread_b {action_b; /return yyyy} 
/syntagma_x -> thread_c {action_c; /return yyyy} 

If the successfully matched thread is the list of bead thread_b then parameter_x value will be yyyy.

A bead always matches a variable with a tag having the same name of the bead's syntagma; e.g. the bead colour^value will match a variable with tag colour.

The lexical syntagmas are defined in a previous chapter. This is a summary of them and a short description of the derived syntagmas available within the kernel:

 
stat^$	matches a Zz statement 
statlist^$	matches' one or more Zz statements divided by ; or EOL
param^ ret	matches a Zz parameter or variable and returns its name 
list_e^ ret	matches a list expression and returns the list 
num_e^ ret	matches a numeric (int or float) expression and returns its value
string_e^ ret	matches a character expression and returns its value 
int^ ret	(lexical) matches a unsigned integer number and returns its value 
float^ ret	(lexical) matches a unsigned float number and returns its value 
ident^ ret	(lexical) matches a identifier and returns its name. 
qstring^ ret	(lexical) matches a quoted string and returns the string. 

It is possible to specify an action to be executed when the action associated to a thread is modified. The syntax is the following:

Please note that the simplest statement to change a syntax is:

But the user usually introduces some statement to automatically modify the syntax, of course at some deepest level the statement is the simplest one.

The action action_a is executed if the action_b associated to the rule /syntagma -> thread is changed.

For example:

zz> /stat -> changing { 
  /print alfa 
} 
zz> /when change action { 
  /print "action changed" 
} 
zz> /stat -> changing { 
  /print beta 
} 
action changed 
zz>

This is the format to create a list:

A list expression is made up with the list concatenation operator: "&". It is possible to refer to an item of a variable containing a list using the following format:

variable is a variable containing a list. item_number is an integer number, lists being indexed with the first item as 1.

The lists are used to introduce blocks of statements (like the actions connected with a rule).

The tokens in the lists are any character with the exception of a right bracket (}) or an unmatched double quote (").

An item in a list can be a variable but regardless from the scope of the variable (LOCAL or GLOBAL) its value is inserted once for all in the list when it is defined.