|
1 | 1 | For the Future |
2 | 2 | ============== |
3 | 3 |
|
4 | | -Additional Format Types |
5 | | ------------------------ |
| 4 | +*One can always dream...* |
6 | 5 |
|
7 | | -There are currently 4 kinds of format types: |
| 6 | +Graphics3D |
| 7 | +---------- |
8 | 8 |
|
9 | | -- ``xml`` (which is really MathML) |
10 | | -- ``text``: ASCII text |
11 | | -- ``tex``: Knuth's TeX typesetting system |
12 | | -- ``boxes``: combinations of the above |
| 9 | +With 4.0.0, we have started defining a Graphics3D protocol. It is |
| 10 | +currently expressed in JSON. There is an independent `threejs-based |
| 11 | +module |
| 12 | +<https://www.npmjs.com/package/@mathicsorg/mathics-threejs-backend>`_ |
| 13 | +to implement this. Tiago Cavalcante Trindade is responsible for this |
| 14 | +code and for modernizing our JavaScript, and it use in threejs. |
13 | 15 |
|
14 | | -Proposed is to add two more: |
| 16 | +We expect a lot more to come. For example UniformPolyhedra is too new |
| 17 | +to have been able to make this release. |
15 | 18 |
|
16 | | -- ``rst``: restructured text |
17 | | -- ``graphics``: a higher-level graphics-package independent format |
| 19 | +We also need to define a protocol and implementation for 2D Graphics. |
18 | 20 |
|
19 | | -The problem with using TeX for formatting is that in of itself it is |
20 | | -more of a low-level formatter. LaTeX was the corresponding |
21 | | -higher-level formatter, but this too is a bit more cumbersome than |
22 | | -current documentation practice. Since the code is Python-based, |
23 | | -ReStructured text now makes more sense since there are good libraries |
24 | | -for that and this integrates with the documentation better described |
25 | | -above. |
26 | 21 |
|
27 | | -Right now for non-text front-ends the XML format is used. Within that, |
28 | | -is an embedded image of some sort like SVG, or PNG. The problem with |
29 | | -this is that decisions have already been baked in with respect to a |
30 | | -number of drawing parameters and those are impossible to undo since |
31 | | -metadata and user-supplied options have been lost. Better graphing and |
32 | | -drawing packages exist which are in a better position to make layout |
33 | | -and drawing parameter if given a chance. |
| 22 | +Boxing, Formatting, Forms |
| 23 | +------------------------- |
34 | 24 |
|
35 | | -Actually, it is often the case it it is not that there are new drawing |
36 | | -packages so much as there are *newer* *versions* of graphic packages and the |
37 | | -Mathics core hasn't been updated to make use of those improvements |
| 25 | +While we have started to segregate boxing (bounding-box layout) and |
| 26 | +formatting (translation to a conventional rendering format or |
| 27 | +language), a lot more work needs to be done. |
38 | 28 |
|
39 | | -In sum, decisions about plotting and drawing need to get moved closer |
40 | | -to the front end which knows better about which drawing packages are |
41 | | -available and what it capabilities are. |
| 29 | +Also, a lot more Forms should be defined. And those that exist, like |
| 30 | +TeXForm, and StandardForm, could use improvement. |
42 | 31 |
|
43 | | -PyModules |
44 | | ---------- |
| 32 | +This area is still a big mess. |
45 | 33 |
|
46 | | -To reduce core depencencies on python and system libraries, allow for |
47 | | -a more distributed growth and speed up startup time, Mathics |
48 | | -introdcued a mechanism which is basically doing a Python ``import`` |
49 | | -which is similar to how its internal built-in and predefined packages |
50 | | -and symbols work. From Mathics the function is called ``LoadModule[]``. |
| 34 | +Jupyter and other Front Ends |
| 35 | +---------------------------- |
51 | 36 |
|
52 | | -Unfortunately, this wasn't scalable and more work is needed. As a |
53 | | -result some modules, notably the module for Natural Language |
54 | | -Processesing (NLP) was removed. |
| 37 | +Although we had planned to move forward on this previously, it now |
| 38 | +appears that we should nail down some of the above better, before |
| 39 | +undertaking. Jupyter uses a wire protocol, and we still have |
| 40 | +work to do in defining the interfaces mentioned above. |
55 | 41 |
|
56 | | -Graph Module |
57 | | -++++++++++++ |
| 42 | +That said, this is still on the horizon. |
58 | 43 |
|
59 | | -A module for working and plotting with graphs was also started and |
60 | | -made one of the few custom PyMathics module. It started to use the |
61 | | -fine `networkx <https://networkx.github.io/>`_ package for showing |
62 | | -graphs. |
63 | | - |
64 | | -However it was using a rather old version *networkx* and there is the |
65 | | -problem of handling graphics in Mathics mentioned above. |
66 | | - |
67 | | -For these reasons rather than provide a somewhat incomplete package, |
68 | | -we optioed for delaying introduction of this until a better job can be |
69 | | -done. |
70 | | - |
71 | | -The hope is that with this package in place we will be able to support |
72 | | -the full `Combinatorica |
73 | | -<http://homepage.divms.uiowa.edu/~sriram/Combinatorica/>`_ package |
74 | | -doing computational discrete mathematics. |
| 44 | +Interest has also been expressed in WebGL, and Flask front ends. But |
| 45 | +these too will require use to have better protocols defined and in |
| 46 | +place. |
75 | 47 |
|
76 | 48 |
|
77 | 49 | Documentation |
78 | 50 | ------------- |
79 | 51 |
|
80 | | -After release 1.1.0, a rethinking of the documentation systems may be |
81 | | -done to reflect 2020's Python-centric tools, thinking and practice. |
82 | | - |
83 | | -This may include integration into RsT/Sphinx/Readthedocs. |
84 | | -Sphinx has a mechanism for embedding testable code into its docs. |
| 52 | +Sometime release 4.0.0, all of the code related to producing |
| 53 | +documentation in LaTeX and in Mathics Django, and running doctests |
| 54 | +will be split off and put into its own git repository. |
85 | 55 |
|
86 | | -Testing |
87 | | -------- |
| 56 | +I've spent a lot of time banging on this to try to get to to be be |
| 57 | +less fragile, more modular, more intelligible, but it still needs a |
| 58 | +*lot* more work and still is very fragile. |
88 | 59 |
|
89 | | -Related to documentation, testing may be modularized better and |
90 | | -expanded. Right now most of the tests are hooked into documentation, |
91 | | -and while this is cool, not all tests are interesting to have in |
92 | | -documentation. In particular, obscure bugs fall into this category. |
| 60 | +Also there is much to do on the editor side of things in terms of |
| 61 | +reorganizing sections (which also implies reorganizing the builtin |
| 62 | +module structure, since those are tightly bound together). |
93 | 63 |
|
94 | | -Command-line interface |
95 | | ----------------------- |
| 64 | +We still need to convert this into Sphinx-based, with its doctest. We |
| 65 | +also need to be able to extract information in sphinx/RsT format |
| 66 | +rather than its home-brew markup language which is sort of XML like. |
96 | 67 |
|
97 | | -In 1.1.0, a new CLI frontend, ``mathicsscript`` was been started. |
| 68 | +Performance |
| 69 | +----------- |
98 | 70 |
|
99 | | -It supports: |
| 71 | +This is one area where we know a lot about what *kinds* of things need |
| 72 | +to be done, but have barely scratched the surface here. |
100 | 73 |
|
101 | | -* Save history over sessions |
102 | | -* Understands groupings of lines which form one logical Mathics statement |
103 | | -* Supports Pygments-based syntax coloring of output, and Pygments styles |
104 | | -* Can automatically detect whether a terminal has a dark or light background |
| 74 | +The current implementation is pretty bare bones. |
105 | 75 |
|
106 | | -With changes to the format types mentioned above and by using |
107 | | -``sympy``'s ASCII rendering routines, ``mathicsscript`` will support |
108 | | -opening a matplotlib window to show graphics, and will display output |
109 | | -in ASCII better. |
| 76 | +We have problems with recursion, memory consumption, loading time, and |
| 77 | +overall speed in computation. |
110 | 78 |
|
111 | | -Jupyter Interface |
112 | | ------------------ |
| 79 | +Support for External Packages |
| 80 | +----------------------------- |
113 | 81 |
|
114 | | -this may happen around January 2021. |
| 82 | +I would have liked to have seen this going earlier. However right now |
| 83 | +Mathics is still at too primitive a level for any serious package to |
| 84 | +be run on it. This will change at some point though. |
115 | 85 |
|
116 | | -In the future, Django may be split off to a separate package, same as |
117 | | -the CLI and existing Jupyter interfaces. |
| 86 | +Support for Mathematica Language Levels |
| 87 | +--------------------------------------- |
118 | 88 |
|
119 | | -It is possbile if IPython via Jupyter works well, the CLI interface |
120 | | -won't be needed. However I (rocky) suspect not. |
| 89 | +This is something that I think would be extremely useful and is |
| 90 | +straightforward to do someone has used Mathematica over the years |
| 91 | +knows it well. I think most of this could be supported in Mathics code |
| 92 | +itself and loaded as packages. Any takers? |
0 commit comments