|
| 1 | +mathics_scanner.characters |
| 2 | +========================== |
| 3 | + |
| 4 | +This module consists mostly of translation tables between Wolfram's internal |
| 5 | +representation and Unicode/ASCII. For maintainability, it was decided to store |
| 6 | +this data in a human-readable YAML table (in ``data/named-characters.yml``). |
| 7 | + |
| 8 | +The YAML table mainly contains information about how to convert a |
| 9 | +named character to Unicode and back. If a given character has a direct Unicode |
| 10 | +equivalent (a Unicode character whose description is similar as the named |
| 11 | +character's), this is specified by the ``unicode-equivalent`` field in the YAML |
| 12 | +table. Note that multiple named characters may share a common |
| 13 | +``unicode-equivalent`` field. Also, if a named character has a Unicode |
| 14 | +equivalent, it's ``unicode-equivalent`` field need not to consist of a single |
| 15 | +Unicode code-point. For example, the Unicode equivalent of ``\[FormalAlpha]`` |
| 16 | +is ``U+03B1 U+0323`` (or ``GREEK SMALL LETTER ALPHA + COMBINING DOT BELOW``). |
| 17 | + |
| 18 | +If a named character has a ``unicode-equivalent`` field whose description fits |
| 19 | +the precise description of the character then it's ``has-unicode-inverse`` |
| 20 | +field in the YAML table is set to ``true``. |
| 21 | + |
| 22 | +The conversion routines ``replace_wl_with_plain_text`` and |
| 23 | +``replace_unicode_with_wl`` use this information to convert between Wolfram's |
| 24 | +internal format and standard Unicode, but it should be noted that the |
| 25 | +conversion scheme is more complex than a simple lookup in the YAML table. |
| 26 | + |
| 27 | +The Conversion Scheme |
| 28 | +--------------------- |
| 29 | + |
| 30 | +The ``replace_wl_with_plain_text`` functions converts text from Wolfram's |
| 31 | +internal representation to standard Unicode *or* ASCII. If set to ``True``, the |
| 32 | +``use_unicode`` argument indicates to ``replace_wl_with_plain_text`` that the |
| 33 | +input should be converted to standard Unicode. If set to ``False``, |
| 34 | +``use_unicode`` indicates to ``replace_wl_with_plain_text`` that it should only |
| 35 | +output standard ASCII. |
| 36 | + |
| 37 | +The algorithm for converting from Wolfram's internal representation to standard |
| 38 | +Unicode is the following: |
| 39 | + |
| 40 | +- If a character has a direct Unicode equivalent then the character is replaced |
| 41 | + by it's Unicode equivalent. |
| 42 | +- If a character doesn't have a Unicode equivalent then the character is |
| 43 | + replaced by it's fully qualified name. For example, the ``\[AliasIndicator]`` |
| 44 | + character (or ``U+F768`` in Wolfram's internal representation) is replaced by |
| 45 | + the Python string ``"\\[AliasIndicator]"``. |
| 46 | + |
| 47 | +The algorithm for converting from Wolfram's internal representation to standard |
| 48 | +ASCII is the following: |
| 49 | + |
| 50 | +- If a character has a direct Unicode equivalent and all of the characters of |
| 51 | + it's Unicode equivalent are valid ASCII characters then the character is |
| 52 | + replaced by it's Unicode equivalent. |
| 53 | +- If a character doesn't have a Unicode equivalent or any of the characters of |
| 54 | + it's Unicode equivalent isn't a valid character then the character is |
| 55 | + replaced by it's fully qualified name. |
| 56 | + |
| 57 | +The ``replace_unicode_with_wl`` function converts text from standard Unicode to |
| 58 | +Wolfram's internal representation. The algorithm for converting from standard |
| 59 | +Unicode to Wolfram's internal representation is the following: |
| 60 | + |
| 61 | +- If a Unicode character sequence happens to match the ``unicode-equivalent`` |
| 62 | + of a Wolfram Language named character whose ``has-unicode-inverse`` field is |
| 63 | + set to ``true``, then the Unicode character is replaced by the Wolfram's internal |
| 64 | + representation of such named character. Note that the YAML table is |
| 65 | + maintained in such a way that there is always *at most* one character that |
| 66 | + fits such description. |
| 67 | +- Otherwise the character is left unchanged. Note that fully qualified names |
| 68 | + (such as the Python string ``"\\[Alpha]"`` or the Python string ``"Alpha"``) are *not* replaced at all. |
| 69 | + |
| 70 | +Optimizations |
| 71 | +------------- |
| 72 | + |
| 73 | +Because of the large size of the YAML table and the relative complexity of the |
| 74 | +conversion scheme, it was decided to store precompiled conversion tables in a |
| 75 | +file and read them from disk at runtime (when the module is imported). Our |
| 76 | +tests showed that storing the tables as JSON and using `ujson |
| 77 | +<https://github.com/ultrajson/ultrajson>`_ to read them is the most efficient |
| 78 | +way to access them. However, this is merely an implementation detail and |
| 79 | +consumers of this library should not rely on this assumption. |
| 80 | + |
| 81 | +The conversion tables are stored in the ``data/characters.json`` file, along |
| 82 | +side other complementary information used internally by the library. |
| 83 | +``data/characters.json`` holds three conversion tables: |
| 84 | + |
| 85 | +- The ``wl-to-unicode`` table, which stores the precompiled results of the |
| 86 | + Wolfram-to-Unicode conversion algorithm. ``wl-to-unicode`` is used for lookup |
| 87 | + when ``replace_wl_with_plain_text`` is called with the ``use_unicode`` |
| 88 | + argument set to ``True``. |
| 89 | +- The ``wl-to-ascii`` table, which stores the precompiled results of the |
| 90 | + Wolfram-to-ASCII conversion algorithm. ``wl-to-ascii`` is used for lookup |
| 91 | + when ``replace_wl_with_plain_text`` is called with the ``use_unicode`` |
| 92 | + argument set to ``False``. |
| 93 | +- The ``unicode-to-wl`` table, which stores the precompiled results of the |
| 94 | + Unicode-to-Wolfram conversion algorithm. ``unicode-to-wl`` is used for lookup |
| 95 | + when ``replace_unicode_with_wl`` is called. |
| 96 | + |
| 97 | +The precompiled translation tables, as well as the rest of data stored in |
| 98 | +``data/characters.json``, is generated from the YAML table with the |
| 99 | +``mathics_scanner.generate.build_tables.compile_tables`` function. |
| 100 | + |
| 101 | +Note that multiple entries in the YAML table are redundant in the following |
| 102 | +sense: when a character has a Unicode equivalent equivalent but the Unicode |
| 103 | +equivalent is the same as it's Wolfram's internal representation (i.e. the |
| 104 | +``wl-unicode`` field is the same as the ``unicode-equivalent`` field in the |
| 105 | +YAML table) then it is considered redundant for us, since no conversion is |
| 106 | +needed. |
| 107 | + |
| 108 | +As an optimization, we explicitly remove any redundant characters from *all* |
| 109 | +precompiled conversion tables. Such optimization makes the tables smaller and |
| 110 | +easier to load. This implies that not all named characters that have a Unicode |
| 111 | +equivalent are included in the precompiled translation tables (the ones that |
| 112 | +are not included are the ones where no conversion is needed). |
| 113 | + |
0 commit comments