Skip to content

Commit

Permalink
[docs] updates regarding translation not using declarative ways
Browse files Browse the repository at this point in the history
  • Loading branch information
apalala committed Aug 24, 2023
1 parent 2100ff6 commit ac597f8
Show file tree
Hide file tree
Showing 2 changed files with 25 additions and 10 deletions.
2 changes: 1 addition & 1 deletion docs/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -47,7 +47,7 @@ input, much like the `re`_ module does with regular expressions, or it can gener
semantics
models
print_translation
templates_translation
translation
left_recursion
mini-tutorial
traces
Expand Down
33 changes: 24 additions & 9 deletions docs/templates_translation.rst → docs/translation.rst
Original file line number Diff line number Diff line change
@@ -1,17 +1,32 @@
.. include:: links.rst

Templates Translation
--------------------------
.. _mini-tutorial: mini-tutorial.rst

.. _pegen: https://github.com/we-like-parsers/pegen
.. _PEG parser: https://peps.python.org/pep-0617/

**deprecated**
Declarative Translation
-----------------------

**note**
As of |TatSu| 3.2.0, code generation was separated from grammar
models through ``tatsu.codegen.CodeGenerator`` as to allow for code
generation targets different from `Python`_. Still, the use of
inline templates and ``rendering.Renderer`` hasn't changed. See the
*regex* example for merged modeling and code generation.
Translation is one of the most common tasks in language processing.
Analysis often sumarizes the parsed input, and *walkers* are good for that.
In translation, the output can often be as verbose as the input, so a systematic approach that avoids bookkeeping as much as possible is convenient.

|TatSu| provides support for template-based code generation ("translation", see below)
in the ``tatsu.codegen`` module.
Code generation works by defining a translation class for each class in the model specified by the grammar.

Nowadays the preferred code generation strategy is to walk down the AST_ and `print()` the desired output,
with the help of the ``NodWalker`` class, and the ``IndentPrintMixin`` mixin. That's the strategy used
by pegen_, the precursor to the new `PEG parser`_ in Python_. Please take a lookt at the
`mini-tutorial`_ for an example.

Basically, the code generation strategy changed from declarative with library support, to procedural,
breadth or depth first, using only standard Python_. The procedural code must know the AST_ structure
to navigate it, although other strategies are available with ``PreOrderWalker``, ``DepthFirstWalker``,
and ``ContextWalker``.

**deprecated**

|TatSu| doesn't impose a way to create translators with it, but it
exposes the facilities it uses to generate the `Python`_ source code for
Expand Down

0 comments on commit ac597f8

Please sign in to comment.