about some criteria about the organization of the code.

[mmatera]

When I was working on #630, I realize that something that could help to avoid/reduce circular dependencies and make the code more readable would be to establish a hierarchy of what modules perform global import from which others.

The proposal would be something like

                                                  mathics.core
                                                             |
                         _______________________________________________________
                        |                                    |                                                     |
            mathics.eval                     mathics.core.convert               mathics.algorithm
                        |                                       |                                                  |
                        |_______________________|_____________________________|
                                                                  |
                                                       mathics.builtin                                                      

Does it make? if it does, maybe some parts of #635 should be reformulated.

[rocky]

In words, is the diagram saying that:

• mathics.eval, mathics.core.convert, mathics.algorthm import from mathics.core generally but not the other way around?
• mathics.builtin imports from everything and not generally not the other way around?

If so, I think that matches how I think of things.

As for reformulating #635 that is fine. The main idea there is that:

• the definitions object instantiation should not contain Builtin module loading code , and conceptually these are two different.
• Furthermore, builtin-module loading is done once; so is predefined or system Builtin creation. This is part of a bigger idea that isn't very well spelled out in WIP module load, and builtin create once #635 that there should be a system-level environment (object) that is set up once. When discussing speeding up startup time then, I believe,in a large part, we are talking about speeding up setting up the system-level environment object.

Finally, let me describe how I view some of the modules above.

mathics.core contains the basic building blocks and implementation of many core ideas, like what primitive datatypes exist. (Lists, M-Expressions, Rationals, MachineReals, Symbols). These have to be implemented in Python.

mathics.core.convert is the part of that which contain functions to get the input into these internal structures or convert between internal structures.

mathics.eval are things that in an instruction interpreter would consider (virtual) instructions. These implement the most-used builtin functions and/or the ones that need to be done the fastest. There might be some additional code in support of the work an instruction needs to do. In other words instructions may need to call other common routines.

mathics.algorithm is a bit of a mish-mash. I don't have a good characterization of this other than there seem to be classes of evaluation methods, maybe higher-level ones, that are in support of instruction evaluation.

mathics.builtin when things get settled, lists top-level evaluation methods found by application. It has various properties of built-ins, that are not characterized elsewhere. That means that outside of parameter checking and simple evaluation transformations, involved code to do evaluation gets migrated out of here. Same for boxing, boxing rules, and rendering/formatting when moved elsewhere.

[mmatera]

In words, is the diagram saying that:

* `mathics.eval`, `mathics.core.convert`, `mathics.algorthm` import from `mathics.core` generally but not the other way around?

* `mathics.builtin` imports from everything and not  generally not the other way around?

What I said is that global imports should satisfy this directionality. Then, local imports, (that should be avoided when it is possible) could do in the opposite way.

If so, I think that matches how I think of things.

Good.

Finally, let me describe how I view some of the modules above.

mathics.core contains the basic building blocks and implementation of many core ideas, like what primitive datatypes exist. (Lists, M-Expressions, Rationals, MachineReals, Symbols). These have to be implemented in Python.

mathics.core.convert is the part of that which contain functions to get the input into these internal structures or convert between internal structures.

mathics.eval are things that in an instruction interpreter would consider (virtual) instructions. These implement the most-used builtin functions and/or the ones that need to be done the fastest. There might be some additional code in support of the work an instruction needs to do. In other words instructions may need to call other common routines.

mathics.algorithm is a bit of a mish-mash. I don't have a good characterization of this other than there seem to be classes of evaluation methods, maybe higher-level ones, that are in support of instruction evaluation.

mathics.builtin when things get settled, lists top-level evaluation methods found by application. It has various properties of built-ins, that are not characterized elsewhere. That means that evaluation, boxing, and rendering/formatting no longer belong when they it makes sense (this has been moved elsewhere). Similarly, Boxing rules will eventually be organized elsewhere.

OK, then let's continue in this direction.