Skip to content

D
DHParser
Commit 73000d4c authored by eckhart's avatar eckhart
Browse files
Options

- StepByStepGuide: minor corrections

parent 76941898
Hide whitespace changes
Inline Side-by-side
Showing with 112 additions and 21850 deletions
DHParser/stringview.py
View file @ 73000d4c
......@@ -208,9 +208,9 @@ class StringView(collections.abc.Sized):
def match(self, regex, flags=0):
"""Executes `regex.match` on the StringView object and returns the
result, which is either a match-object or None.
WARNING: match.end(), match.span() etc. are mapped to the underlying text,
not the StringView-object!!!
result, which is either a match-object or None. Keep in mind that
match.end(), match.span() etc. are mapped to the underlying text,
not the StringView-object!!!
"""
return regex.match(self.text, pos=self.begin, endpos=self.end)
......@@ -236,17 +236,16 @@ class StringView(collections.abc.Sized):
def search(self, regex):
"""Executes regex.search on the StringView object and returns the
result, which is either a match-object or None.
WARNING: match.end(), match.span() etc. are mapped to the underlying text,
not the StringView-object!!!
result, which is either a match-object or None. Keep in mind that
match.end(), match.span() etc. are mapped to the underlying text,
not the StringView-object!!!
"""
return regex.search(self.text, pos=self.begin, endpos=self.end)
def finditer(self, regex):
"""Executes regex.finditer on the StringView object and returns the
iterator of match objects.
WARNING: match.end(), match.span() etc. are mapped to the underlying text,
not the StringView-object!!!
iterator of match objects. Keep in mind that match.end(), match.span()
etc. are mapped to the underlying text, not the StringView-object!!!
"""
return regex.finditer(self.text, pos=self.begin, endpos=self.end)
......
DHParser/transform.py
View file @ 73000d4c
......@@ -920,4 +920,3 @@ def forbid(context: List[Node], child_tags: AbstractSet[str]):
if child.tag_name in child_tags:
context[0].new_error(node, 'Element "%s" cannot be nested inside "%s".' %
(child.parser.name, node.parser.name))
documentation/.buildinfo deleted 100644 → 0
View file @ 76941898
# Sphinx build info version 1
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
config: a864fbe9973eb04d25fc99fca3d8ce3e
tags: 645f666f9bcd5a90fca523b33c5a78b7
documentation/ModuleReference.html deleted 100644 → 0
View file @ 76941898
This source diff could not be displayed because it is too large. You can view the blob instead.
documentation/ReferenceManual.html deleted 100644 → 0
View file @ 76941898
<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>DHParser Reference Manual &mdash; DHParser 0.8 documentation</title>
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="Module Reference" href="ModuleReference.html" />
<link rel="prev" title="DHParser User’s Guide" href="UserGuide.html" />
<script src="_static/js/modernizr.min.js"></script>
</head>
<body class="wy-body-for-nav">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-scroll">
<div class="wy-side-nav-search">
<a href="index.html" class="icon icon-home"> DHParser
</a>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
<input type="text" name="q" placeholder="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
<p class="caption"><span class="caption-text">Contents:</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="StepByStepGuide.html">DHParser’s Step by Step Guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="UserGuide.html">DHParser User’s Guide</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">DHParser Reference Manual</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#fundamentals">Fundamentals</a></li>
<li class="toctree-l2"><a class="reference internal" href="#compiler-creation-workflow">Compiler Creation Workflow</a></li>
<li class="toctree-l2"><a class="reference internal" href="#component-guide">Component Guide</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#parser">Parser</a></li>
<li class="toctree-l3"><a class="reference internal" href="#ast-transformation">AST-Transformation</a></li>
<li class="toctree-l3"><a class="reference internal" href="#compiler">Compiler</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="#module-structure-of-dhparser">Module Structure of DHParser</a></li>
<li class="toctree-l2"><a class="reference internal" href="#class-hierarchy-of-dhparser">Class Hierarchy of DHParser</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="ModuleReference.html">Module Reference</a></li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">DHParser</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href="index.html">Docs</a> &raquo;</li>
<li>DHParser Reference Manual</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/ReferenceManual.rst.txt" rel="nofollow"> View page source</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="dhparser-reference-manual">
<h1>DHParser Reference Manual<a class="headerlink" href="#dhparser-reference-manual" title="Permalink to this headline"></a></h1>
<p>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.</p>
<div class="section" id="fundamentals">
<h2>Fundamentals<a class="headerlink" href="#fundamentals" title="Permalink to this headline"></a></h2>
<p>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 <em>editing data
format</em> and a maschine friendly <em>working data format</em> which can be XML
but does not need to be. Therefore, the DSL-approach requires an
additional step to reach the <em>working data format</em>, 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 <em>document</em>. The
editing data format will also be called <em>source format</em> and the
working data format be denoted as <em>target format</em>.</p>
<p>Compiling a document specified in a domain specific language involves the following steps:</p>
<ol class="arabic simple">
<li><strong>Parsing</strong> the document which results in a representation of the document as a concrete
syntax tree.</li>
<li><strong>Transforming</strong> the concrete syntax tree (CST) into an abstract syntax tree (AST), i.e. a
streamlined and simplified syntax tree ready for compilation.</li>
<li><strong>Compiling</strong> the abstract syntax tree into the working data format.</li>
</ol>
<p>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 <em>parser</em>, a <em>transformer</em> and a
<em>compiler</em>. 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:</p>
<ol class="arabic simple">
<li><em>Creating a parser</em>: 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
<cite>examples/EBNF/EBNF.ebnf</cite> for an example.)</li>
<li><em>Specifying the AST-transformations</em>: DHParser supports the AST-transformation with a
depth-first tree traversal algorithm (see <cite>DHParser.transform.traverse</cite> ) 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
<cite>DHParser.ebnf.EBNF_AST_transformation_table</cite> as an example.</li>
<li><em>Filling in the compiler class skeleton</em>: 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 <cite>examples/EBNF/EBNFCompiler.py</cite>) 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.</li>
</ol>
</div>
<div class="section" id="compiler-creation-workflow">
<h2>Compiler Creation Workflow<a class="headerlink" href="#compiler-creation-workflow" title="Permalink to this headline"></a></h2>
<p>TODO: Describe:
- setting up a new projekt
- invoking the DSL Compiler
- conventions and data types
- the flat namespace of DH Parser</p>
</div>
<div class="section" id="component-guide">
<h2>Component Guide<a class="headerlink" href="#component-guide" title="Permalink to this headline"></a></h2>
<div class="section" id="parser">
<h3>Parser<a class="headerlink" href="#parser" title="Permalink to this headline"></a></h3>
<p>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 <cite>class Node</cite> defined in <cite>DHParser/snytaxtree.py</cite></p>
<p>The EBNF to Python compiler is actually a DSL-compiler that has been crafted with DHParser
itself. It is located in <cite>DHParser/enbf.py</cite>. The formal specification of the EBNF variant
used by DHParser can be found in <cite>examples/EBNF/EBNF.ebnf</cite>. Comparing the automatically
generated <cite>examples/EBNF/EBNFCompiler.py</cite> with <cite>DHParser/ebnf.py</cite> 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.</p>
</div>
<div class="section" id="ast-transformation">
<h3>AST-Transformation<a class="headerlink" href="#ast-transformation" title="Permalink to this headline"></a></h3>
<p>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.</p>
</div>
<div class="section" id="compiler">
<h3>Compiler<a class="headerlink" href="#compiler" title="Permalink to this headline"></a></h3>
</div>
</div>
<div class="section" id="module-structure-of-dhparser">
<h2>Module Structure of DHParser<a class="headerlink" href="#module-structure-of-dhparser" title="Permalink to this headline"></a></h2>
</div>
<div class="section" id="class-hierarchy-of-dhparser">
<h2>Class Hierarchy of DHParser<a class="headerlink" href="#class-hierarchy-of-dhparser" title="Permalink to this headline"></a></h2>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">
<a href="ModuleReference.html" class="btn btn-neutral float-right" title="Module Reference" accesskey="n" rel="next">Next <span class="fa fa-arrow-circle-right"></span></a>
<a href="UserGuide.html" class="btn btn-neutral" title="DHParser User’s Guide" accesskey="p" rel="prev"><span class="fa fa-arrow-circle-left"></span> Previous</a>
</div>
<hr/>
<div role="contentinfo">
<p>
&copy; Copyright 2018, Eckhart Arnold.
</p>
</div>
Built with <a href="http://sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/rtfd/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>.
</footer>
</div>
</div>
</section>
</div>
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT:'./',
VERSION:'0.8',
LANGUAGE:'None',
COLLAPSE_INDEX:false,
FILE_SUFFIX:'.html',
HAS_SOURCE: true,
SOURCELINK_SUFFIX: '.txt'
};
</script>
<script type="text/javascript" src="_static/jquery.js"></script>
<script type="text/javascript" src="_static/underscore.js"></script>
<script type="text/javascript" src="_static/doctools.js"></script>
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
<script type="text/javascript" src="_static/js/theme.js"></script>
<script type="text/javascript">
jQuery(function () {
SphinxRtdTheme.Navigation.enableSticky();
});
</script>
</body>
</html>
\ No newline at end of file
documentation/StepByStepGuide.html deleted 100644 → 0
View file @ 76941898
<!DOCTYPE html>
<!--[if IE 8]><html class="no-js lt-ie9" lang="en" > <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en" > <!--<![endif]-->
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>DHParser’s Step by Step Guide &mdash; DHParser 0.8 documentation</title>
<link rel="stylesheet" href="_static/css/theme.css" type="text/css" />
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="DHParser User’s Guide" href="UserGuide.html" />
<link rel="prev" title="Welcome to DHParser’s documentation!" href="index.html" />
<script src="_static/js/modernizr.min.js"></script>
</head>
<body class="wy-body-for-nav">
<div class="wy-grid-for-nav">
<nav data-toggle="wy-nav-shift" class="wy-nav-side">
<div class="wy-side-scroll">
<div class="wy-side-nav-search">
<a href="index.html" class="icon icon-home"> DHParser
</a>
<div role="search">
<form id="rtd-search-form" class="wy-form" action="search.html" method="get">
<input type="text" name="q" placeholder="Search docs" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="main navigation">
<p class="caption"><span class="caption-text">Contents:</span></p>
<ul class="current">
<li class="toctree-l1 current"><a class="current reference internal" href="#">DHParser’s Step by Step Guide</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#setting-up-a-new-dhparser-project">Setting up a new DHParser project</a><ul>
<li class="toctree-l3"><a class="reference internal" href="#installing-dhparser-from-the-git-repository">Installing DHParser from the git repository</a></li>
<li class="toctree-l3"><a class="reference internal" href="#staring-a-new-dhparser-project">Staring a new DHParser project</a></li>
<li class="toctree-l3"><a class="reference internal" href="#understanding-how-compilation-of-dsl-documents-with-dhparser-works">Understanding how compilation of DSL-documents with DHParser works</a></li>
<li class="toctree-l3"><a class="reference internal" href="#the-development-workflow-for-dsls">The development workflow for DSLs</a></li>
<li class="toctree-l3"><a class="reference internal" href="#extending-the-example-dsl-further">Extending the example DSL further</a></li>
<li class="toctree-l3"><a class="reference internal" href="#controlling-abstract-syntax-tree-generation">Controlling abstract-syntax-tree generation</a></li>
</ul>
</li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="UserGuide.html">DHParser User’s Guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="ReferenceManual.html">DHParser Reference Manual</a></li>
<li class="toctree-l1"><a class="reference internal" href="ModuleReference.html">Module Reference</a></li>
</ul>
</div>
</div>
</nav>
<section data-toggle="wy-nav-shift" class="wy-nav-content-wrap">
<nav class="wy-nav-top" aria-label="top navigation">
<i data-toggle="wy-nav-top" class="fa fa-bars"></i>
<a href="index.html">DHParser</a>
</nav>
<div class="wy-nav-content">
<div class="rst-content">
<div role="navigation" aria-label="breadcrumbs navigation">
<ul class="wy-breadcrumbs">
<li><a href="index.html">Docs</a> &raquo;</li>
<li>DHParser’s Step by Step Guide</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/StepByStepGuide.rst.txt" rel="nofollow"> View page source</a>
</li>
</ul>
<hr/>
</div>
<div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article">
<div itemprop="articleBody">
<div class="section" id="dhparser-s-step-by-step-guide">
<h1>DHParser’s Step by Step Guide<a class="headerlink" href="#dhparser-s-step-by-step-guide" title="Permalink to this headline"></a></h1>
<p>This step by step guide goes through the whole process of desining and testing
a domain specific notation from the very start. (The terms “domain specific
noation” and “domain specific language” are used interchangeably in the
following. Both will abbreviated by “DSL”, however.) We will design a simple
domain specific notation for poems as a teaching example. On the way we will
learn:</p>
<ol class="arabic simple">
<li>how to setup a new DHParser project</li>
<li>how to use the test driven development approach to designing a DSL</li>
<li>how to describe the syntax of a DSL with the EBNF-notation</li>
<li>how to specify the transformations for converting the concrete syntax tree
that results from parsing a text denoted in our DLS into an abstract syntax
tree that represents or comes close to representing out data model.</li>
<li>how to write a compiler that transforms the abstract syntax tree into a
target representation which might be a html page, epub or printable pdf in
the case of typical Digital-Humanities-projects.</li>
</ol>
<div class="section" id="setting-up-a-new-dhparser-project">
<h2>Setting up a new DHParser project<a class="headerlink" href="#setting-up-a-new-dhparser-project" title="Permalink to this headline"></a></h2>
<p>Since DHParser, while quite mature in terms of implemented features, is still
in a pre-first-release state, it is for the time being more recommendable to
clone the most current version of DHParser from the git-repository rather than
installing the packages from the Python Package Index (PyPI).</p>
<p>This section takes you from cloning the DHParser git repository to setting up
a new DHParser-project in the <code class="docutils literal notranslate"><span class="pre">experimental</span></code>-subdirectory and testing
whether the setup works. Similarily to current web development practices, most
of the work with DHParser is done from the shell. In the following, we assume
a Unix (Linux) environment. The same can most likely be done on other
operating systems in a very similar way, but there might be subtle
differences.</p>
<div class="section" id="installing-dhparser-from-the-git-repository">
<h3>Installing DHParser from the git repository<a class="headerlink" href="#installing-dhparser-from-the-git-repository" title="Permalink to this headline"></a></h3>
<p>In order to install DHParser from the git repository, open up a shell window
and type:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ git clone git@gitlab.lrz.de:badw-it/DHParser.git
$ cd DHParser
</pre></div>
</div>
<p>The second command changes to the DHParser directory. Within this directory
you should recognise the following subdirectories and files. There are more
files and directories for sure, but those will not concern us for now:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>DHParser/ - the DHParser python packages
documentation/ - DHParser&#39;s documentation in html-form
documentation_source - DHParser&#39;s documentation in reStructedText-Format
examples/ - some exmamples for DHParser (mostly incomplete)
experimental/ - an empty directory for experimenting
test/ - DHParser&#39;s unit-tests
dhparser.py - DHParser&#39;s command line tool for setting up projects
README.md - General information about DHParser
LICENSE.txt - DHParser&#39;s license. It&#39;s open source (hooray!)
Introduction.md - An introduction and appetizer for DHParser
</pre></div>
</div>
<p>In order to verify that the installation works, you can simply run the
“dhparser.py” script and, when asked, chose “3” for the self-test. If the
self-test runs through without error, the installation has succeded.</p>
</div>
<div class="section" id="staring-a-new-dhparser-project">
<h3>Staring a new DHParser project<a class="headerlink" href="#staring-a-new-dhparser-project" title="Permalink to this headline"></a></h3>
<p>In order to setup a new DHParser project, you run the <code class="docutils literal notranslate"><span class="pre">dhparser.py</span></code>-script
with the name of the new project. For the sake of the example, let’s type:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ python dhparser.py experimental/poetry
$ cd experimental/poetry
</pre></div>
</div>
<p>This creates a new DHParser-project with the name “poetry” in directory with
the same name within the subdirectory “experimental”. This new directory
contains the following files:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">README</span><span class="o">.</span><span class="n">md</span> <span class="o">-</span> <span class="n">a</span> <span class="n">stub</span> <span class="k">for</span> <span class="n">a</span> <span class="n">readme</span><span class="o">-</span><span class="n">file</span> <span class="n">explaiing</span> <span class="n">the</span> <span class="n">project</span>
<span class="n">poetry</span><span class="o">.</span><span class="n">ebnf</span> <span class="o">-</span> <span class="n">a</span> <span class="n">trivial</span> <span class="n">demo</span> <span class="n">grammar</span> <span class="k">for</span> <span class="n">the</span> <span class="n">new</span> <span class="n">project</span>
<span class="n">example</span><span class="o">.</span><span class="n">dsl</span> <span class="o">-</span> <span class="n">an</span> <span class="n">example</span> <span class="n">file</span> <span class="n">written</span> <span class="ow">in</span> <span class="n">this</span> <span class="n">grammar</span>
<span class="n">tst_poetry_grammar</span><span class="o">.</span><span class="n">py</span> <span class="o">-</span> <span class="n">a</span> <span class="n">python</span> <span class="n">script</span> <span class="p">(</span><span class="s2">&quot;test-script&quot;</span><span class="p">)</span> <span class="n">that</span> <span class="n">re</span><span class="o">-</span><span class="n">compiles</span>
<span class="n">the</span> <span class="n">grammar</span> <span class="p">(</span><span class="k">if</span> <span class="n">necessary</span><span class="p">)</span> <span class="ow">and</span> <span class="n">runs</span> <span class="n">the</span> <span class="n">unit</span> <span class="n">tests</span>
<span class="n">grammar_tests</span><span class="o">/</span><span class="mi">01</span><span class="n">_test_word</span><span class="o">.</span><span class="n">ini</span> <span class="o">-</span> <span class="n">a</span> <span class="n">demo</span> <span class="n">unit</span> <span class="n">test</span>
<span class="n">grammar_tests</span><span class="o">/</span><span class="mi">02</span><span class="n">_test_document</span><span class="o">.</span><span class="n">ini</span> <span class="o">-</span> <span class="n">another</span> <span class="n">unit</span> <span class="n">test</span>
</pre></div>
</div>
<p>Now, if you look into the file “example.dsl” you will find that it contains a
simple sequence of words, namely “Life is but a walking shadow”. In fact, the
demo grammar that comes with a newly created project is nothing but simple
grammar for sequences of words separated by whitespace. Now, since we alread
have unit tests, our first exercise will be to run the unit tests by starting
the script “tst_poetry_grammar.py”:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ python tst_poetry_grammar.py
</pre></div>
</div>
<p>This will run through the unit-tests in the grammar_tests directory and print
their success or failure on the screen. If you check the contents of your
project directory after running the script, you might notice that there now
exists a new file “poetryCompiler.py” in the project directory. This is an
auto-generated compiler-script for our DSL. You can use this script to compile
any source file of your DSL, like “example.dsl”. Let’s try:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ python poetryCompiler.py example.dsl
</pre></div>
</div>
<p>The output is a block of pseudo-XML, looking like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">&lt;</span><span class="n">document</span><span class="o">&gt;</span>
<span class="o">&lt;</span><span class="p">:</span><span class="n">ZeroOrMore</span><span class="o">&gt;</span>
<span class="o">&lt;</span><span class="n">WORD</span><span class="o">&gt;</span>
<span class="o">&lt;</span><span class="p">:</span><span class="n">RegExp</span><span class="o">&gt;</span><span class="n">Life</span><span class="o">&lt;/</span><span class="p">:</span><span class="n">RegExp</span><span class="o">&gt;</span>
<span class="o">&lt;</span><span class="p">:</span><span class="n">Whitespace</span><span class="o">&gt;</span> <span class="o">&lt;/</span><span class="p">:</span><span class="n">Whitespace</span><span class="o">&gt;</span>
<span class="o">&lt;/</span><span class="n">WORD</span><span class="o">&gt;</span>
<span class="o">&lt;</span><span class="n">WORD</span><span class="o">&gt;</span>
<span class="o">&lt;</span><span class="p">:</span><span class="n">RegExp</span><span class="o">&gt;</span><span class="ow">is</span><span class="o">&lt;/</span><span class="p">:</span><span class="n">RegExp</span><span class="o">&gt;</span>
<span class="o">&lt;</span><span class="p">:</span><span class="n">Whitespace</span><span class="o">&gt;</span> <span class="o">&lt;/</span><span class="p">:</span><span class="n">Whitespace</span><span class="o">&gt;</span>
<span class="o">&lt;/</span><span class="n">WORD</span><span class="o">&gt;</span>
<span class="o">...</span>
</pre></div>
</div>
<p>Now, this does not look too helpful yet, partly, because it is cluttered with
all sorts of seemingly superflous pseudo-XML-tags like “&lt;:ZeroOrMore&gt;”.
However, you might notice that it contains the original sequence of words
“Life is but a walkting shadow” in a structured form, where each word is
(among other things) surrounded by &lt;WORD&gt;-tags. In fact, the output of the
compiler script is a pseudo-XML-representation of the <em>contrete syntax tree</em>
of our “example.dsl”-document according the grammar specified in “poetry.ebnf”
(which we haven’t looked into yet, but we will do so soon).</p>
<p>If you see the pseudo-XML on screen, the setup of the new DHParser-project
has been successful.</p>
</div>
<div class="section" id="understanding-how-compilation-of-dsl-documents-with-dhparser-works">
<h3>Understanding how compilation of DSL-documents with DHParser works<a class="headerlink" href="#understanding-how-compilation-of-dsl-documents-with-dhparser-works" title="Permalink to this headline"></a></h3>
<p>Generally speaking, the compilation process consists of three stages:</p>
<ol class="arabic simple">
<li>Parsing a document. This yields a <em>concrete syntax tree</em> (CST) of the
document.</li>
<li>Transforming. This transforms the CST into the much more concise <em>abstract
syntax tree</em> (AST) of the document.</li>
<li>Compiling. This turns the AST into anything you’d like, for example, an
XML-representation or a relational database record.</li>
</ol>
<p>Now, DHParser can fully automize the generation of a parser from a
syntax-description in EBNF-form, like our “poetry.ebnf”, but it cannot
automize the transformation from the concrete into the abstract syntax tree
(which for the sake of brevity we will simply call “AST-Transformation” in the
following), and neither can it automize the compilation of the abstract syntax
tree into something more useful. Therefore, the AST-Transformation in the
autogenerated compile-script is simply left empty, while the compiling stage
simply converts the syntax tree into a pseudo-XML-format.</p>
<p>The latter two stages have to be coded into the compile-script by hand, with
the support of templates within this script. If the grammar of the DSL is
changed - as it will be frequently during the development of a DSL - the
parser-part of this script will be regenerated by the testing-script before
the unit tests are run. The script will notice if the grammar has changed.
This also means that the parser part of this script will be overwritten and
should never be edited by hand. The other two stages can and should be edited
by hand. Stubs for theses parts of the compile-script will only be generated