GNTicker

GNTicker is an interpreter for a certain kind of reduced generalized nets (GN). It can be run as a standalone program or as a server, which allows simultaneous execution of multiple GN models. The software application is written in C++ for CLBME by Kalin Georgiev and Trifon Trifonov.

Generalized net models are described (or coded, programmed) on two levels. First of all, the structure of the model is defined in an XML file. This definition includes description of the GN’s transitions, places, tokens and matrices. Each GN component is given a unique name (identifier) and the structure of the XML definition allows the interpreter to extract information about the relations between those components. In the place definitions and predicate matrix definitions, characteristic functions and predicates are only referred by their names. Their actual definitions come in the second part of the GN code – the GNTCFL program.

GNTCFL is a language with Lisp-like syntax developed especially for GNTicker. A GNTCFL program is a set of function definitions that can be used as characteristic functions and predicates as well as user defined utility functions.

The XML definition of a GN model structure and the GNTCFL program with definitions of characteristic functions and predicates form the complete GN code which can be “executed” by GNTicker. The “execution” process is actually an interpretation of the definitions and a calculation of token characteristic for each step of some GN’s life. GNTCFL provides certain tracing capabilities that allow characteristics of various tokens to be printed to the standard output or sent to another process and eventually recorded to form the “result” of the GN’s execution. The recorded data can be visualized later, or during the GN model execution. The MS Windows version of GNTicker has primitive support for real-time visualization of function graphics.

Basic concept

The presented GNTicker is an interpreter for a certain kind of reduced Generalized Nets (GN). It provides capabilities to code a GN by describing its structure and programming its characteristic functions and predicates, execute it and trace the execution.

Running the interpreter

This version of GNTicker interpreter is an executable which needs the following files to operate:

• gnticker.exe – the interpreter
• gnschema.xsd – not described here
• xerces-c_2_1_0.dll – Xerces XML interface library

In order to run a GN use the following command line syntax:

gnticker <GN description file> <steps>

Programming a GN

A GN description consists of

• A GN model structure described in an XML file (see section 2);
• Characteristic functions, predicates and user-defined functions coded in the XML definition, or in separate GNTCFL files, referred to in the XML. (see section 3).

Detailed view of the XML definition

The GN model structure is defined in XML 1.0 syntax. A comprehensive set of XML tag and attribute definitions is shown on the following tree diagram. The tags are displayed in rectangles and the attributes - in ellipses. Required attributes are underlined.

Description of the XML tags

• <gn> - the root tag of the GN definition
• <transitions>, <tokens>, <places> - contain one or more definitions for transitions,

tokens and places, respectively

• <transition>, <token>, <place> - contain a separate definition for each of the

corresponding GN elements <generator> - a definition of a token generator, extends the <token> tag

• <char> - a named characteristic definition, contains the initial value of the

characteristic. This can be:

• • a real constant for type “double”
  • a vector constant for type “vector” - a list of constants, enclosed in square brackets (for example: [1 “string” 3.5])
  • any other value is treated like a string constant for type “string”
• <functions> - contain inline definitions of GNTCFL functions and empty <import> tags with filenames of files to import
• <inputs>, <outputs> - contain a list of the identifiers of the input and output places

for the transition

• <predicates> - contains a list of the identifiers of predicates, defined in the GNCTFL file. The list describes the predicate matrix of the transition, which is listed row by row, starting with the first. The list must contain exactly m.n identifiers, where m and n are the number of input and output places of the transition. Valid identifiers are also “true” and “false”, which represent the corresponding constant predicates.

Description of the XML attributes

• id – an identifier for the corresponding element. All identifiers must be unique.
• priority – a non-negative integer, stating the priority of the transition, token or place. Default priority is 0.
• gn.name – a description of the GN model
• gn.time – the lifetime of the model on the global time scale. Must be positive.
• import.fundefs – the name of the imported GNTCFL file used for characteristic functions and predicates for this model. A full absoulte or relative path must be specified.
• place.capacity – an integer >= -1, which states the capacity of the place, default is -1 meaning infinity.
• place.char – the identifier of a characteristic function for the place, defined in the GNCTFL file (see Section 3). A valid identifier is also “ID” that represents the identity function, which is also the default characteristic function, if a value for this attribute is not specified.
• place.merge – a boolean value (1,0, true, false), which states whether the tokens in this place merge
• place.mergeRule – the identifier of a characteristic GNTCFL function with a single parameter, which defines the way in which token characteristics merge
• token.host – the identifier of a place, where the token enters the GN
• token.entering – the time moment in which the token enters the GN model, a non-negative integer, default is 0 – the starting moment of the GN life.
• token.leaving – the time moment in which the token should leave the GN model (“die”). An integer >= -1, default is -1, meaning infinity.
• char.name – the name of the named characteristic, must be an identifier
• char.type – describes the type of the token characteristic. Possible values are “double”, “string”, “vector”.
• char.history – an integer >= 1, showing the number of characteristics, which the token keeps as history. The value is 1 by default, stating that the token “remembers” only its last characteristic.
• generator.period – the period of a periodic generator. By default 1 (every step).
• generator.predicate – the activation condition of a conditional generator. By default “true” (every step).
• generator.type – a string, specifying the type of generator:
  • periodic – emits a token every period time steps
  • conditional – emits a token on each time step, for which predicate evaluates to true

Example: test.xml

        <?xml version=”1.0”?>
        <gn name=”A Test GN” time=”10”>
                <transitions>
                <transition id=”Z1”>
                        <inputs> P1 P2        </inputs>
                        <outputs> P2 </outputs>
                        <predicates>
                                true
                                less_than_10
                        </predicates>
                </transition>
        </transitions>
        <places>
                <place id=”P1”/>
                <place id=”P2” char=”inc”/>
        </places>
        <tokens>
                <token id=”T1” host=”P1”>
                        <char name=”Default” type=”double”> 0 </char>
                </token>
        </tokens>
        <functions>
                (defun inc “” () ()
                        (set (+ token 1)))
                (defun less_than_10 “1;tokens.T1.char” () ()
                        (< #0 10))
        </functions>
        </gn>

The GNTCFL language

GNTCFL is a programming language of LISP-style syntax. Despite its resemblance to LISP, it is not a fully declarative programming language since it contains certain procedural elements.

The main purpose of the language is to provide the capability of defining GN characteristic functions and predicates as well as user-defined functions used in them.

GNTCFL syntax

LISP-styled, the syntax of GNTCFL programs is very simple. It follows the BNF:

  <program> ::= <function definition>...
  <function definition> ::= (defun <unique name> <frame definition> ([<formal arguments>]) ([<local variables>]) <expression>...)
  <frame definition> ::= “<number of references>;<reference>;...”
  <formal arguments> ::= <unique name>...
  <local variables> ::= <unique name>...
  <expression> ::= (<supercombinator> [<argument>...])
  <supercombinator> ::= <primitive> | <special form> | <user-defined function>
  <special form> ::= if | for | and | or | let
  <argument> ::= <formal argument> | <local variable> | <constant> | <frame index> | <expression>
  <frame index> ::= #<number>

Frame definitions, special forms, primitives and user-defined functions are described in details in the following sections.

GNTCFL semantics

As mentioned above, a GNTCFL program consists entirely of function definitions. As in functional languages there is a general rule for expression evaluating, which applies to all combinations except special forms. The semantics of special forms are specific for each of them and are described separately.

Let

(<supercombinator> [<argument>...])

be an expression, where the supercombinator is not a special form. Evaluating the expression involves subsequent evaluation of the arguments, prior to the application of the supercombinator over their values. In terms of the functional programming the expression evaluations follow the so called applicative model. The following example includes only primitives and constants and demonstrates the process

    (* 2 3 (- 11 (+ 1 1) (/10 5)))
 -> (* 2 3 (- 11 2 (/10 5)))
 -> (* 2 3 (- 11 2 2))
 -> (* 2 3 7)
 -> 42

The if special form

The if special form is an exception from the evaluation rule.

 <if-expression> ::= (if <condition> <then> [<else>])
 <condition> ::= <expression>
 <then> ::= <expression>
 <else> ::= <expression>

After the conditional expression has been evaluated, the process continues with evaluating only one of <then> and <else> expressions, according to the condition value. Thus the following expression is evaluated to 42 instead of raising a “division by zero” error:

 (if (* 1 1) (* 7 6) (/ 8 0))

The for special form

 <for-expression> ::= (for <local-variable> <start-value> <end-value> <step> <expression>)

The <local-variable> is assigned values starting from <start-value>, increased or decreased by <step> to reach <end-value>. On every assignment, <expression> is evaluated. The result is the last evaluation of <expression>. The <local-variable> must be declared in the defun construction (see 3.1)

The while special form

 <while-expression> ::= (while <condition> <expression>)

Evaluation of the while special form involves consequent evaluation of <condition> and <expression>. If <condition> evaluates to a zero value, the process of evaluation is completed and the result is the last value of <expression>.

The let special form

<let-expression> ::= (let <local-variable> <expression>)

The let special form is an assignment construction. First <expression> is evaluated and then its value is assigned to the <local-variable>. In all expressions in the same function, following the let construction, <local-variable> is evaluated to its assigned value. Consequent assignment of different values to the same local variable is possible. In that case the latest assignment is valid.

Primitives

The primitives are built-in functions providing standard operations (arithmetical, input/output, etc). For a complete list of implemented primitives see appendix A.

User-defined functions

As shown in the previous sections, a function definition includes its frame definition, formal arguments and local variables.

Frames

Whenever a function needs to access some property of a GN component such as (and mainly) the characteristic of a named token, it needs to declare a reference in the so called function frame. The frame is a list of all needed GN properties. Frames describe an environment of network components for the functions. The BNF of the frame definitions is:

 <frame definition> ::= “<number of references>;<reference>;...”
 <reference> ::= tokens.<unique name>. obj | tokens.<unique name>. char | places.<unique name>. obj | file.<file name>.<file extension>

where only reference definitions for the recently implemented reference types are given.

For example let us suppose that some function needs the characteristic of a token named “MyToken” and a reference to a place named “MyPlace”. The frame definition will look like

 “2;tokens.MyToken.char;places.MyPlace.obj”.

With this frame the network components properties will be referable in the function body as #0 and #1, respectively.

Declaring an user-defined function

As shown above, a user-defined function definition follows the BNF:

 <function definition> ::= (defun <unique name> <frame definition> ([<formal arguments>]) ([<local variables>]) <expression>...)

Having described of all the major components, let us go straight to the example:

 (defun factorial "" (x) () (if (= x 0) 1 (* x (factorial (- x 1))))

Here x is a local variable and the semantics of the expression has already been discussed.

Let us now define a function that gets the square of the default characteristic of some token named “MyToken” and afterward adds 5 to it if there is at least one token in place “MyPlace”.

        (defun square "" (x) () (* x x))
        (defun myfunction "2;tokens.MyToken.char;places.MyPlace.obj" () (sq)

                                                ;assign the square of the
                                                ;characteristic to the local variable
                                                ;sq
                        (let sq (square #0))
                                                ;return sq or sq + 5
                        (if (exists #1) (+ sq 5) sq))

In this example sq is a local variable and the special form let is used to assign some value to it so that it can be used afterward in all following expressions. The value of the last expression of the function body forms the functions value.

Characteristic functions and predicates

The characteristic function is applied to each token entering the place. Characteristic functions are user-defined functions, which use primitive like set, set-nth, setnamed, split to set the new value of the characteristic of the token to which the function is applied. The functions are referred by their names in the char and mergeRule attributes of the <place> tag.

Predicates are user-defined functions, which return a numeric value. Zero is considered false and any other value - true. Names of predicates are listed in the <predicates> tag, when describing the predicate matrix of a transition. A predicate is evaluated whenever a token tries to pass through the transition from an input place to an output place.

Some reserved words are defined only for the characteristic functions and predicates. The reserved word time is evaluated as an integer, showing the current step of the GN. The reserved word token can be used only in characteristic functions, and is evaluated as the value of the last value of the “Default” named characteristic of the token having entered the place.

The reserved word tokenobj is also defined only for characteristic functions and is valuated to a reference to the token the function is applied to.

Finally, here is an example of GNTCFL definitions for test.xml.

        (defun inc "" () ()
                (set (+ token 1)))
        (defun less_than_10 “1;tokens.T1.char” () ()
                (< #0 10))

References

• GNTicker v0.2 - A Brief Description
• More about GNTicker
• GNTicker Wiki