| 修訂 | ef1c39bd73ea4dba0bcfcf0a7e0bf65b53ff975c (tree) |
|---|---|
| 時間 | 2022-05-14 07:51:11 |
| 作者 | Albert Mietus < albert AT mietus DOT nl > |
| Commiter | Albert Mietus < albert AT mietus DOT nl > |
Small text-refactoring
CCastle/Usage/CompilerCompiler.rst (diff)| @@ -4,9 +4,9 @@ | ||
| 4 | 4 | Compiler Compiler |
| 5 | 5 | ================= |
| 6 | 6 | |
| 7 | -.. post:: 2022/05/20 | |
| 8 | - :category: Castle | |
| 9 | - :tags: Castle | |
| 7 | +.. post:: 2022/05/7 | |
| 8 | + :category: Castle, Usage | |
| 9 | + :tags: Castle, grammar | |
| 10 | 10 | |
| 11 | 11 | In Castle you can define a *grammar* directly in your code. The compiler will *translate* them into functions, using |
| 12 | 12 | the build-in (PEG) **compiler-compiler** -- at least that was it called back in the days of *YACC*. |
| @@ -21,11 +21,11 @@ | ||
| 21 | 21 | |
| 22 | 22 | .. code-block:: PEG |
| 23 | 23 | |
| 24 | - castle_file <- ( import_line | interface | implementation )* ; | |
| 25 | - import_line <- IMPORT_stmt ( STRING_literal | qualID ) ';' ; | |
| 26 | - qualID <- '.'? nameID ('.' nameID )* ; | |
| 27 | - IMPORT_stmt = "import" ; | |
| 28 | - ... | |
| 24 | + castle_file <- ( import_line | interface | implementation )* ; | |
| 25 | + import_line <- IMPORT_stmt ( STRING_literal | qualID ) ';' ; | |
| 26 | + qualID <- '.'? nameID ('.' nameID )* ; | |
| 27 | + IMPORT_stmt = "import" ; | |
| 28 | + ... | |
| 29 | 29 | |
| 30 | 30 | |
| 31 | 31 | This basically defines that a ``castle_file`` is either an ``import_line``, an ``interface``, an ``implementation``, or |
| @@ -62,16 +62,20 @@ | ||
| 62 | 62 | |
| 63 | 63 | There a many ways to *parse*. You do not need a full-fledged grammer to translate “42” into :math:`42` or |
| 64 | 64 | :math:`42.0` --a stdlib functions as ``atoi()`` or ``atof()`` will do. But how about handling complex numbers |
| 65 | -(:math:`4+j2`), fractions (:math:`\frac{17}{42}`)? | |
| 65 | +(:math:`4+j2`) or fractions (:math:`\frac{17}{42}`)? | |
| 66 | 66 | |
| 67 | 67 | Non-parsing |
| 68 | 68 | ----------- |
| 69 | 69 | |
| 70 | 70 | As proper passing used to hard, other similar (but simpler) techniques do exist, like `globing |
| 71 | -<https://en.wikipedia.org/wiki/Glob_(programming)>`__ (\*.Castle on the bash-prompt will result in all | |
| 71 | +<https://en.wikipedia.org/wiki/Glob_(programming)>`__ (``\*.Castle`` on the bash-prompt will result in all | |
| 72 | 72 | Castle-files). Using `regular-expressions <https://en.wikipedia.org/wiki/Regular_expression>`__ is more powerfull, and |
| 73 | -other used to highlight code; a pattern as `//.*$` can be used to highlight (single-line) comment. It often works, but | |
| 73 | +often used to highlight code; a pattern as ``//.*$`` can be used to highlight (single-line) comment. It often works, but | |
| 74 | 74 | this simple pattern might match a piece of text *inside* a multi-line-(doc)string -- which wrong. |
| 75 | +|BR| | |
| 76 | +To parse a input-text its not a sound solution; although I have seen cunning regular-expressions, that almost always | |
| 77 | +work. But *reg-exps* have not the same power as a grammar-- That is already proven halve a century ago and will not be | |
| 78 | +repeated here. | |
| 75 | 79 | |
| 76 | 80 | Grammars are more powerfull |
| 77 | 81 | =========================== |
| @@ -117,4 +121,4 @@ | ||
| 117 | 121 | But typically you proces/use that tree: like you do in many situations. Read the configuration values, walk over the |
| 118 | 122 | tree, of traverse it as-if it is a DOM. You can even use Castle’s :ref:`matching-statements` to simply that. |
| 119 | 123 | |
| 120 | -Grammars makes reading text easy. Define the structure, call the “main rule” and use the values. Castle make it simple. | |
| 124 | +Grammars makes reading text easy. Define the structure, call the “main rule” and use the values. Castle makes that simple! |
Fork