LLOOP Examples

The examples introduced here are part of the release package and are located below the examples/ directory.

The LLOOP project files (.lloop) are provided for all examples and allow to compile and run each of them standalone from the graphical interface, on all supported platforms. These examples serve also as validation and non-regression test suite and can be compiled and run in batch using the overall project file examples/examples.lloop.

Examples split into two categories: academic examples and real-life applications. Academic examples have usually a small size, are easy to understand, and focus on the demonstration of a few features. Real-life examples are bigger applications which make a synthetic use of many features; they demonstrate usefulness and aptitudes for concrete applications.

Academic Examples Overview

Real-life Applications Overview

external_symbols

Academic example that parses sample basic english sentences and intended to show how to refer to external symbols defined outside in a not-imported gsp spec file, using the writing spec.symbol.

The gsp spec files of this example allow to parse sample basic english sentences composed of a noun, a transitive verb and a direct object. The nouns and the direct objects feature an article and optionally multiple adjectives.

The first gsp spec file english_sentence.gsp defines the core syntax rules for the accepted sentences whilst english_adjectives.gsp defines the available adjectives.

english_sentence.gsp does not import english_adjectives.gsp, but refers to the symbols defined there as external symbols by prefixing their base names with the gsp spec file name where they are defined in.

Gsp Spec File(s) and Additional File(s)

infinite_loop

Academic example for a typical wrong syntax rule writing leading to a parsing that loops endlessly till to crash with a memory overflow.

The problem here stems from the symbol dummy_symbol that can always reduce to nothing. If any of the other rules can't be resolved, the parent symbol endlessly attempts and succeeds to parse dummy_symbol. To avoid this problem, the empty rule of the dummy_symbol should be removed and the rule | dummy_symbol [ inf_loop ] should be turned into | [dummy_symbol [ inf_loop ]].

Gsp Spec File(s) and Additional File(s)

iterations

Academic example defining a syntax rule with nested repetitive symbol sequences. Features a self-test where input and expected output are defined outside in external files.

Gsp Spec File(s) and Additional File(s)

minic

Parser for a C-like mini-language. This example shows how to write a C-like mini-language parser. It is useful for measuring performance of the generated parsers.

Gsp Spec File(s) and Additional File(s)

nobacktracking

Academic example showing problems which might arise from the lack of backtracking.

The intent of this example is to show a case where the lack of backtracking makes some kind of input unparsable.

Note:

• While the lack of backtracking reduces the range of acceptable grammars, the dependance on it may also reveal a weak grammar design that will result in poor performance during parsing. Backtracking is a quite inefficient process and may hide syntactical ambiguities which may be better to regard upstream in the grammar or the language design.

The little example implements a kind of command interpreter for performing operations on files. The name of the file must be provided first, followed by ':' and a command keyword ('remove', 'create'...). It is assumed that file names can be made of any printable char including ':' (this corresponds to the string token).

E.g. the interpreter shall be able to understand the following command for removing the file 'README.txt':

README.txt: remove

Now, the interpreter will actually fail to parse this example as defined by the grammar referred to hereafter. Since no space char has been used to separate README.txt from ':', the whole string 'README.txt:' will be parsed as a valid file name. As ':' is expected afterwards and is missing, the parsing fails.

Backtracking in this case would be useful, because the parser would have looked backwards for another rule that would enable a successful parsing of the whole input. The second rule | word of the symbol filename would have allowed to parse successfully the input.

Gsp Spec File(s) and Additional File(s)

selftests

This example is mainly used to run self-tests of all standard preprocessors, symbols and tokens. It also gives an example of how to specify that a symbol is not expected using the meta-symbol !.

Gsp Spec File(s) and Additional File(s)

shape

Academic example used in the tutorial. Also used to check error messages on various cases of syntax errors.

Gsp Spec File(s) and Additional File(s)

palette

Academic example used in the tutorial.

Gsp Spec File(s) and Additional File(s)

gspc_args_v1.0

Parser for the gspc v1.0 command line arguments. Shows how to write parsers for command line options using strict EBNF, without the gspc-specific advanced support for command line options.

Gsp Spec File(s) and Additional File(s)

gspc_arguments

Parser for the gspc v1.1 command line arguments. Useful to show how to benefit of gspc's avanced support for command line options introduced in version 1.1 (GUI, formatted usage and help message...).

Gsp Spec File(s) and Additional File(s)

gspc_license

Parser for the gspc compiler license files. Simple example that features a self-test taking its input from a file.

Gsp Spec File(s) and Additional File(s)

gspc_rc

Parser used by the gspc compiler to translate symbol references within reduction codes in gsp spec files into the actual C++ code. Features self-tests and nested optional and repetitive symbol sequences.

This example is useful to show how to define repetitive symbols inside a rule. This gsp spec file is used to parse references to parsed symbol objects within reduction codes. These references are translated afterwards to the actual source code standing for the requested objects.

Examples of references are the following: #1 for the first constant, $1 for the first non-terminal or token, &1 for a pointer to the first non-terminal or token. If the symbol is iterative, a multi-dimension index has to be given. E.g. $1(0,1) refers to the second iteration within the first occurrence of the upper including iteration. $1(#) returns the number of items parsed in the first iteration.

Gsp Spec File(s) and Additional File(s)

ini_file

An Ini File component implementation. Shows how the content of structured data file can easily be modified simply by parsing the file, changing the parsed symbol objects in memory, and reverse-parsing (expanding) them to an output file for saving. Contains also examples of error outputs and backtracing.

This Ini File component implementation bases only on one gsp spec file and a hand-written class 'IniFile' (see IniFile.h and IniFile.cpp). This short implementation makes it very readable and maintainable.

The spec file testini.gsp is used to test the ini file component and shows examples of how to read, modify and write ini files from your own code.

The file conf.cfg is an example of ini file that can be read by the parser.The conf.cfg.sav is an example of an ini file object that was parsed from the previous file, modified through data section and data field removals/additions/updates, and finally expanded to save changes.

This is an example of syntax error automatically reported using the outputFailureContext() function:

25: TestData3=1 2 3 it's sunny
26: TestData4=1 2 3 it's windy
27: 
28: [TestSection2]
29: Dummy1 just dummy
    _______^
30: Dummy2=just another dummy
31: 
32: [TestSection3]
33: Dummy2=I've got a recipe for writing good code 

This is an example of backtrace that can be output for the above syntax error:

SIniFile => SectionList  [Rule 0 ] 
   |__ SectionList => '[' BlockToken ']' ' ' '\n' DataList SectionList  [Rule 0 ] 
      |__ BlockToken = 'General'
      |__ DataList => WordToken '=' BlockToken '\n' DataList  [Rule 0 ] 
         |__ WordToken = 'Name'
         |__ BlockToken = 'test ini file for LLOOP '
         |__ DataList => WordToken '=' BlockToken '\n' DataList  [Rule 0 ] 
            |__ WordToken = 'Path'
            |__ BlockToken = '/home/mehl/lloop/test/ini_file/examples/conf.cfg '
      |__ SectionList => '[' BlockToken ']' ' ' '\n' DataList SectionList  [Rule 0 ] 
         |__ BlockToken = 'TestSection1'
         |__ DataList => WordToken '=' BlockToken '\n' DataList  [Rule 0 ] 
            |__ WordToken = 'TestData1'
            |__ BlockToken = '1 2 3 hello  '
            |__ DataList => WordToken '=' BlockToken '\n' DataList  [Rule 0 ] 
               |__ WordToken = 'TestData2'
               |__ BlockToken = '1 2 3 it's rainy'
               |__ DataList => WordToken '=' BlockToken '\n' DataList  [Rule 0 ] 
                  |__ WordToken = 'TestData3'
                  |__ BlockToken = '1 2 3 it's sunny'
                  |__ DataList => WordToken '=' BlockToken '\n' DataList  [Rule 0 ] 
                     |__ WordToken = 'TestData4'
                     |__ BlockToken = '1 2 3 it's windy'
         |__ SectionList => '[' BlockToken ']' ' ' '\n' DataList SectionList  [Rule 0 ] 
            |__ BlockToken = 'TestSection2'
conf.cfg: parse error.

Gsp Spec File(s) and Additional File(s)

makedoc

Makedoc is a GUI-based HTML documentation generator for C, C++, and Qt-enhanced C++, which focus on simplicity of use and source code independence.

It intends to provide a tool that relieves the developer from acquiring new technical skills and bringing source code adaptations for specific tools. Makedoc should make it possible to create shareable documentation for most source codes without modification and within minutes, simply by opening the GUI, entering the path(s) to its source code files the first time, and clicking on the generation button.

Check this link for further information.

Gsp Spec File(s) and Additional File(s)

This file is part of the LLOOP Reversible Object-Oriented Parser Generator. Copyright (c) 2005-2006 Michel MEHL, France. All rights reserved. LLOOP is distributed by the company ERSA SaRL.