Commit beb4bedc authored by di68kap's avatar di68kap
Browse files

- dsl.py: transform.rstrip and transform.lstrip now properly included in generated python modules

parent e3f28126
......@@ -42,3 +42,5 @@ examples/Tutorial/LyrikCompiler.py
_build
_static
_templates
.vs
OLDSTUFF
......@@ -99,7 +99,7 @@ from DHParser import logging, is_filename, load_if_file, \\
is_empty, is_expendable, collapse, replace_content, WHITESPACE_PTYPE, TOKEN_PTYPE, \\
remove_nodes, remove_content, remove_brackets, replace_parser, \\
keep_children, is_one_of, has_content, apply_if, remove_first, remove_last, \\
remove_anonymous_empty, keep_nodes, traverse_locally, strip
remove_anonymous_empty, keep_nodes, traverse_locally, strip, lstrip, rstrip
'''.format(dhparserdir=dhparserdir)
......
*****************************
DHParser's Step by Step Guide
*****************************
......@@ -32,10 +31,12 @@ 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).
This section takes you from cloning the DHParser git repository to setting up
a new DHParser-project in the ``experimental``-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.
This section takes you from cloning the DHParser git repository to setting up a
new DHParser-project in the ``experimental``-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.
Installing DHParser from the git repository
-------------------------------------------
......@@ -119,12 +120,13 @@ The output is a block of pseudo-XML, looking like this::
...
Now, this does not look too helpful yet, partly, because it is cluttered with
all sorts of seemingly superflous pseudo-XML-tags like "<:ZeroOrMore>".
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 <WORD>-tags. In fact, the output of the
compiler script is a pseudo-XML-representation of the *contrete syntax tree* 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).
all sorts of seemingly superflous pseudo-XML-tags like "<:ZeroOrMore>". 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 <WORD>-tags. In fact, the output of the compiler script is a
pseudo-XML-representation of the *contrete syntax tree* 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).
If you see the pseudo-XML on screen, the setup of the new DHParser-project
has been successful.
......@@ -143,13 +145,17 @@ Generally speaking, the compilation process consists of three stages:
3. Compiling. This turns the AST into anything you'd like, for example, an
XML-representation or a relational database record.
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.
The latter to stages have to be coded into the compile-script by hand, using
the existing templates within this script. If the grammar of the DSL is
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.
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.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment