Skip to content

GitLab

Commit 73000d4c authored by eckhart's avatar eckhart
Browse files

- StepByStepGuide: minor corrections

parent 76941898
Expand all Show whitespace changes
Inline Side-by-side
DHParser/stringview.py
View file @ 73000d4c
...@@ -208,8 +208,8 @@ class StringView(collections.abc.Sized): ...@@ -208,8 +208,8 @@ class StringView(collections.abc.Sized):
def match(self, regex, flags=0): def match(self, regex, flags=0):
"""Executes `regex.match` on the StringView object and returns the """Executes `regex.match` on the StringView object and returns the
result, which is either a match-object or None. result, which is either a match-object or None. Keep in mind that
WARNING: match.end(), match.span() etc. are mapped to the underlying text, match.end(), match.span() etc. are mapped to the underlying text,
not the StringView-object!!! not the StringView-object!!!
""" """
return regex.match(self.text, pos=self.begin, endpos=self.end) return regex.match(self.text, pos=self.begin, endpos=self.end)
...@@ -236,17 +236,16 @@ class StringView(collections.abc.Sized): ...@@ -236,17 +236,16 @@ class StringView(collections.abc.Sized):
def search(self, regex): def search(self, regex):
"""Executes regex.search on the StringView object and returns the """Executes regex.search on the StringView object and returns the
result, which is either a match-object or None. result, which is either a match-object or None. Keep in mind that
WARNING: match.end(), match.span() etc. are mapped to the underlying text, match.end(), match.span() etc. are mapped to the underlying text,
not the StringView-object!!! not the StringView-object!!!
""" """
return regex.search(self.text, pos=self.begin, endpos=self.end) return regex.search(self.text, pos=self.begin, endpos=self.end)
def finditer(self, regex): def finditer(self, regex):
"""Executes regex.finditer on the StringView object and returns the """Executes regex.finditer on the StringView object and returns the
iterator of match objects. iterator of match objects. Keep in mind that match.end(), match.span()
WARNING: match.end(), match.span() etc. are mapped to the underlying text, etc. are mapped to the underlying text, not the StringView-object!!!
not the StringView-object!!!
""" """
return regex.finditer(self.text, pos=self.begin, endpos=self.end) 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]): ...@@ -920,4 +920,3 @@ def forbid(context: List[Node], child_tags: AbstractSet[str]):
if child.tag_name in child_tags: if child.tag_name in child_tags:
context[0].new_error(node, 'Element "%s" cannot be nested inside "%s".' % context[0].new_error(node, 'Element "%s" cannot be nested inside "%s".' %
(child.parser.name, node.parser.name)) (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
This diff is collapsed.
documentation_sources/StepByStepGuide.rst → documentation/StepByStepGuide.rst
View file @ 73000d4c
...@@ -391,7 +391,7 @@ What have we got, there? We've got a paragraph that consists of several ...@@ -391,7 +391,7 @@ What have we got, there? We've got a paragraph that consists of several
sentences each of which ends with a full stop. The sentences themselves can sentences each of which ends with a full stop. The sentences themselves can
consist of different parts which a separated by a comma. If, so far, we have consist of different parts which a separated by a comma. If, so far, we have
got a clear idea (in verbal terms) of the structure of texts in our DSL, we got a clear idea (in verbal terms) of the structure of texts in our DSL, we
can now try to formulate this in the grammar. can now try to formulate this in the grammar.::
document = ~ { sentence } §EOF document = ~ { sentence } §EOF
sentence = part {"," part } "." sentence = part {"," part } "."
...@@ -415,7 +415,7 @@ code above?) For all less intelligent people, like me: Let's be prudent and - ...@@ -415,7 +415,7 @@ code above?) For all less intelligent people, like me: Let's be prudent and -
since the grammar has become more complex - add a few test cases. This should since the grammar has become more complex - add a few test cases. This should
make it easier to locate any errors. So open up an editor with a new file in make it easier to locate any errors. So open up an editor with a new file in
the tests subdirectory, say ``grammar_tests/03_test_sentence.ini`` (Test files the tests subdirectory, say ``grammar_tests/03_test_sentence.ini`` (Test files
should always contain the component "test_" in the filename, otherwise they should always contain the component `test_` in the filename, otherwise they
will be overlooked by DHParser's unit testing subsystem) and enter a few will be overlooked by DHParser's unit testing subsystem) and enter a few
test-cases like these:: test-cases like these::
......
documentation/UserGuide.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 User’s 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 Reference Manual" href="ReferenceManual.html" />
<link rel="prev" title="DHParser’s Step by Step Guide" href="StepByStepGuide.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 current"><a class="current reference internal" href="#">DHParser User’s Guide</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#introduction">Introduction</a></li>
</ul>
</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 User’s Guide</li>
<li class="wy-breadcrumbs-aside">
<a href="_sources/UserGuide.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-user-s-guide">
<h1>DHParser User’s Guide<a class="headerlink" href="#dhparser-user-s-guide" title="Permalink to this headline"></a></h1>
<p>This user’s guide explains how to use create, test and employ a domain
specific language with DHParser for encoding text or data in a Digital
Humanities Project.</p>
<div class="section" id="introduction">
<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline"></a></h2>
<p>Most Digital Humanities projects or least most text-centered DH projects
involve in some way or other the entering and encoding of annotated text or
data into a computer. And the systems that scientists use for that purpose
consist of an input surface (or “redactation system”) for entering the data, a
storage system to keep the data and a presentation system for providing the
data and possibly also functionality for working with the data to human or
machine receipients. A typical example of this type of system is Berlin’
Ediarum-System, which consists of an XML-Editor for entering data, an
XML-Database for storing the data and a web application for providing the data
to human readers or other web services via an application programming
interface (API). Ediarum is also typical, because like many DH-projects it
assumes an XML-based workflow.</p>
</div>
</div>
</div>
</div>
<footer>
<div class="rst-footer-buttons" role="navigation" aria-label="footer navigation">