DHParser Reference Manual

This reference manual explains the technology used by DHParser. It is intended for people who would like to extend or contribute to DHParser. The reference manual does not explain how a Domain Specific Language (DSL) is developed (see the User’s Manual for that). It it explains the technical approach that DHParser employs for parsing, abstract syntax tree transformation and compilation of a given DSL. And it describes the module and class structure of the DHParser Software. The programming guide requires a working knowledge of Python programming and a basic understanding or common parser technology from the reader. Also, it is recommended to read the introduction and the user’s guide first.

Fundamentals

DHParser is a parser generator aimed at but not restricted to the creation of domain specific languages in the Digital Humanities (DH), hence the name “DHParser”. In the Digital Humanities, DSLs allow to enter annotated texts or data in a human friendly and readable form with a Text-Editor. In contrast to the prevailing XML-approach, the DSL-approach distinguishes between a human-friendly editing data format and a maschine friendly working data format which can be XML but does not need to be. Therefore, the DSL-approach requires an additional step to reach the working data format, that is, the compilation of the annotated text or data written in the DSL (editing data format) to the working data format. In the following a text or data file wirtten in a DSL will simply be called document. The editing data format will also be called source format and the working data format be denoted as target format.

Compiling a document specified in a domain specific language involves the following steps:

1. Parsing the document which results in a representation of the document as a concrete syntax tree.
2. Transforming the concrete syntax tree (CST) into an abstract syntax tree (AST), i.e. a streamlined and simplified syntax tree ready for compilation.
3. Compiling the abstract syntax tree into the working data format.

All of these steps a carried out be the computer without any user intervention, i.e. without the need of humans to rewrite or enrich the data during any these steps. A DSL-compiler therefore consists of three components which are applied in sequence, a parser, a transformer and a compiler. Creating, i.e. programming these components is the task of compiler construction. The creation of all of these components is supported by DHParser, albeit to a different degree:

1. Creating a parser: DHParser fully automizes parser generation. Once the syntax of the DSL is formally specified, it can be compiled into a python class that is able to parse any document written in the DSL. DHParser uses Parsing-Expression-Grammars in a variant of the Extended-Backus-Naur-Form (EBNF) for the specification of the syntax. (See examples/EBNF/EBNF.ebnf for an example.)
2. Specifying the AST-transformations: DHParser supports the AST-transformation with a depth-first tree traversal algorithm (see DHParser.transform.traverse ) and a number of stock transformation functions which can also be combined. Most of the AST-transformation is specified in a declarative manner by filling in a transformation-dictionary which associates the node-types of the concrete syntax tree with such combinations of transformations. See DHParser.ebnf.EBNF_AST_transformation_table as an example.
3. Filling in the compiler class skeleton: Compiler generation cannot be automated like parser generation. It is supported by DHParser merely by generating a skeleton of a compiler class with a method-stub for each definition (or “production” as the definition are sometimes also called) of the EBNF-specification. (See examples/EBNF/EBNFCompiler.py) If the target format is XML, there is a chance that the XML can simply be generated by serializing the abstract syntax tree as XML without the need of a dedicated compilation step.

Compiler Creation Workflow

TODO: Describe: - setting up a new projekt - invoking the DSL Compiler - conventions and data types - the flat namespace of DH Parser

Component Guide

Parser

Parser-creation if supported by DHParser by an EBNF to Python compiler which yields a working python class that parses any document the EBNF-specified DSL to a tree of Node-objects, which are instances of the class Node defined in DHParser/snytaxtree.py

The EBNF to Python compiler is actually a DSL-compiler that has been crafted with DHParser itself. It is located in DHParser/enbf.py. The formal specification of the EBNF variant used by DHParser can be found in examples/EBNF/EBNF.ebnf. Comparing the automatically generated examples/EBNF/EBNFCompiler.py with DHParser/ebnf.py can give you an idea what additional work is needed to create a DSL-compiler from an autogenerated DSL-parser. In most DH-projects this task will be less complex, however, as the target format is XML which usually can be derived from the abstract syntax tree with fewer steps than the Python code in the case of DHParser’s EBNF to Python compiler.

AST-Transformation

Other than for the compiler generation (see the next point below), a functional rather than object-oriented approach has been employed, because it allows for a more concise specification of the AST-transformation since typically the same combination of transformations can be used for several node types of the AST. It would therefore be tedious to fill in a method for each of these. In a sense, the specification of AST-transformation constitutes an “internal DSL” realized with the means of the Python language itself.

Compiler

Module Structure of DHParser

Class Hierarchy of DHParser

 eckhart committed May 01, 2018 273   eckhart committed Apr 02, 2018 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294