Demo 0 - Hello World

The HelloWorld Example. The GIGL source (left), the C++ interaction (top-right), and an execution I/O example (bottom-right).

View the GIGL source file in the Git repo

Instructions:

• • As a demo, the first step is to try compiling and running the given project. For instructions and tips about demos please refer to [Here].

  • When running the demo, it will first ask to input an integer as a random seed, then it goes into a loop of asking to input any character until the character 'q' is entered which marks the termination. This I/O process is encoded in C++ as the top-right of the figure indicates, and the example result is shown in the bottom right of the figure.

  • The same random seed might not give the exactly same result across different environments (difference in C++ library for RNG). The result shown in the figure is done on a Windows machine with Visual Studio 2015. In addition, the development of GIGL might also change some of the ordering of getting random numbers which might also affect the concrete results. Nevertheless, statistically, the results should be of the same distribution, as the semantics of the GIGL code does not change.

  • After the demo is working, you may want to try further reading the GIGL code and/or the notes below to get a better understanding of GIGL's syntax and semantics.

Comments/Notes:

• • GIGL support comments the same way as C/C++, for both block comment (Line 1 - 4) and line comment (Line 7). Although here the comments are just for demo (and fun), and it is not the recommended way to use them. Note that, unless specified, all line numbers for GIGL code in the demo sections are the line numbers in the figure, which might be different in the actual source file.

  • In general, GIGL code should start with giglstart (Line 5), and have an item type definition starting with the gigltype (Line 7 - 20). The type name can later be used as a C++ class. If the main function is not in the GIGL code, i.e. other C++ or GIGL code needs to interact with this one, it also needs to include some C++ compatible interface, often functions that generate items of the type defined.

  • The item type definition is organized in blocks, just like the public, private and protected blocks in C++ class definition. Node blocks (Line 9) define attributes that appears on each node in the item three. Nonterminal blocks (Line 12) declares the nonterminal types (symbols) in the item grammar, and rule blocks (Line 15 - 19) define rules in the item grammar and the generator behavior when expanding through the rule. There is another type of blocks called wrapper block which does not appear in this example and is for encoding attributes that applies at the item level. A detailed illustration and discussion of the framework item type definition can be found [Here].

  • Here the (parametrizable) item grammar encoded is

  • Message := helloWorld()

  • | helloMom(),

  • where "helloWorld" and "helloMom" are the names of the two rules and they both expands to an empty nonterminal (i.e. no child). It randomly chooses one type of greeting message out of the two.

  • Here the only node attribute is "Print" (Line 9), which is a functional attribute, a function that operates recursively on each node in the item tree and print the text of the greeting. The implementation for it is in the scope of each rule. And the assignment like implementation for "Print" is just an alias for a function implementation that returns the "HelloWorld" as a string (see [Here] for more details).

  • In the interfacing function "GenerateGreeting" (Line 22 - 25), generate ... with ... (Line 23 - 24) calls the item generator (which is implicitly defined within the item type) with the generator configuration.

• The generator configuration is wrapped in <* and *> (Line 22 - 25), which parameterize the item grammar and its associated generation process. Here by

• Message := helloWorld | helloMom (Line 24),

  • we are implicitly defining that choose "helloWorld" or "helloMom" rule with equal likelihood. This is effectively same as explicitly specify probability by replacing that part with

  • Message := helloWorld @ {0.5} | helloMom @ {0.5} ,

  • you can achieve the same effect. GIGL automatically divides the remaining probability that are not specified (here it is 1.0) to rules without a probability field in the configuration.

• Following the notes above, if you replace that part with

  • Message := helloMom ,

  • or explicitly

  • Message := helloWorld @ {0.0} | helloMom @ {1.0} ,

  • you can achieve the result that it always chooses "helloMom" but never "helloWorld". GIGL automatically assigns zero probability to rules that does not appear at all in the configuration.