Start noting what's up and what goals have been met

FUTURE.rst

@@ -2,6 +2,91 @@
 
 .. contents::
 
+The following 2023 roadmap that appears the 6.0.0 hasn't gone through enough discussion. This provisional.
+Check the github repository for updates.
+
+
+2023 Roadmap
+============
+
+
+When the release settles, "Forms, Boxing, And "Formatting" is the next
+large refactor slated.  Having this will allow us to supporting Jupyter or other front
+ends. And it is something that is most visibly wrong in Mathics3 output.
+
+See ``PAST.rst`` for how the 2023 Roadmap compares to the 2022 Roadmap.
+
+Forms, Boxing and Formatting
+----------------------------
+
+This remains the biggest holdover item from 2022, and seems easily doable.
+It hinders interaction with Jupyter or other front ends.
+
+Right now "Form" (a high-level specification of how to format) and
+"format" (a low level specification of how output is encoded) are sometimes muddied.
+
+For example, TeXForm may be a "Form", but output encoded for AMS-LaTeX is done by a *formatter*.
+So AMS-LaTeX rendering and other kinds of rendering should be split into its own rendering for formatter module.
+Currently we have asymptote, and svg "format" modules.
+
+Back to high-level again, Boxing is something that can be written in Mathics3, and doing this at
+least initally ensures that we have design that fits more naturally
+into the Wolfram Language philosophy.
+
+
+Performance
+-----------
+
+While this is probably more of an overall concert, for now, the winds and bigger tasks like
+going over pattern matching will get done after Forms, Boxing and Formatting .
+
+Forms, Boxing and Formatting will however contain one improvement that
+should speed up our performance: separating M-Expression evaluation from
+Box "evaluations).
+
+
+More Custom kinds of (compound) Expressions
++++++++++++++++++++++++++++++++++++++++++++
+
+We scratched the surface here with ListExpression. Associations and Python/Sympy/numpy literals can be customized with an aim towards reducing conversions from and to M-expressions.
+A number of compound expressions, especially those which involve literals are more efficiently represented in some other way. For example
+an Association as a Python ordered dictionary, a List as a Python list or tuple, or as a numpy array.
+
+
+Further Code Reorganization in Core and Eval
+--------------------------------------------
+
+Core object like BaseElement and possibly Symbol, although no doubt there are others are too "fat". They have too many custom methods that are not applicable for most of the subclasses support.
+It is likely another pass will be made over this.
+
+We have started moving "eval" code out of the "eval" menthods and into its own
+
+Mathics3 Module Enhancement
+---------------------------
+
+While we have put in quite a bit of effort to get these to be 6.0.0 compliant. There is still more work to do, and numerous bugs there.
+Refactoring code to generate Graphs in pymathics.graph might happen. Porting the pymathics.graph code to use NetworkX 3.0 would be nice.
+Pymathics.natlang could also use a look over in terms of the libraries we are using.
+
+
+Deferred
+--------
+
+As mentioned before, pattern-matching revision is for later. There are probably various scoping/context issues that need work that will be deferred.
+
+Way down the line, is converting to a more sequence-based interpreter which is needed for JIT'ing and better Compilation support.
+
+Likewise, speeding up startup time via saving and loading an image is something that is more of a long-term goal.
+
+
+Miscellaneous
+-------------
+
+No doubt there will be numerous bug fixes, and builtin-function additions especially not that we have a better framework to support this kind of growth.
+Some of the smaller deferred issues refactorings may get addressed.
+
+
+
 2022 Roadmap
 =============
 

PAST.rst

@@ -0,0 +1,52 @@
+While ``FUTURE.rst`` gives our current roadmap, this file ``PAST.rst``
+looks the other way for what we have accomplished when compared to what _was_ planned in ``FUTURE.rst``
+
+While this is also listed in ``CHANGES.rst``, here we extract that to
+make it easier to see the bigger picture without the details that are
+in ``CHANGES.rst``.
+
+Progress from 2022
+==================
+
+A fair bit of code refactoring has gone on so that we might be able to
+scale the code, get it to be more performant, and more in line with
+other interpreters.
+
+The buitin Functions have been organized into grouping akind to what is found in WMA.
+This is not just for documentation purposes, but it better modularizes the code and keep
+the modules smaller while suggesting where functions below as we scale.
+
+Image Routines have been gone over.
+
+A number of Built-in functions that were implemented were not accessible for various reasons.
+
+Mathics3 Modules are better integrated into the documentation.
+Existing Mathics3 modules pymathics.graph and pymathics.natlang have
+had a major overhaul, although more is needed. And will continue after th 6.0.0 release
+
+
+Boxing and Formatting
+---------------------
+
+While some work on formatting is done has been made and the change in API reflects a little of this.
+However a lot more work needs to be done.
+
+Excecution Performance
+----------------------
+
+This has improved a slight bit, but not because it has been a focus, but
+rather because in going over the code organization, we are doing this
+less dumb, e.g. using Symbols more where symbols are intended. Or
+fixing bugs like resetting mpmath numeric precision on operations that
+need to chnage it temporarily.
+
+Simpler Things
+--------------
+
+A number of items here remain, but should not be thought as independent items, but instead part of
+"Forms, Boxing and Formatting".
+
+"Making StandardOutput of polynomials match WMA" is really are Forms, Boxing and Formatting issue;
+"Working on Jupyter integrations" is also very dependant this.
+
+So the next major refactor will be on Forms, Boxing and Formatting.