Centralize import/export statements and clean up main file

[lgoettgens]

Nemocas/Nemo.jl#1601 for AbstractAlgebra

Edit: some parts have already been merged as #1556

[lgoettgens]

Most of the work was already done by @fingolfin in #1281.

Some open questions on how to proceed:

1. Why are there two long export lists in AbstractAlgebra.jl (one starting around line 220, the other around line 790)?
2. For the submodules (Generic and PrettyPrinting) there is currently a mix of exporting their functions from the submodule and importing into the main AbstractAlgebra module. Which of the two is the one to use?

[codecov]

Codecov Report

Attention: Patch coverage is 90.00000% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 86.69%. Comparing base (435ec91) to head (1fff81a).
Report is 4 commits behind head on master.

Files	Patch %	Lines
src/WeakValueDict.jl	88.88%	1 Missing ⚠️
src/julia/Matrix.jl	87.50%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1537      +/-   ##
==========================================
- Coverage   86.76%   86.69%   -0.08%     
==========================================
  Files         114      114              
  Lines       29696    29652      -44     
==========================================
- Hits        25767    25707      -60     
- Misses       3929     3945      +16     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fingolfin]

1. Why are there two long export lists in AbstractAlgebra.jl (one starting around line 220, the other around line 790)?

Probably historic reasons? I would try to merge everything into the first list and see what happens.

2. For the submodules (Generic and PrettyPrinting) there is currently a mix of exporting their functions from the submodule and importing into the main AbstractAlgebra module. Which of the two is the one to use?

Maybe I am missing something in your question, but I don't think the two are interchangeable in general?

• if foo is defined before module Generic is loaded, then Generic must import it
• if foo is only defined *after module Generic, then Generic cannot import it; and if code outside Generic is supposed to use foo or even install methods for it, then Generic but must export it

[lgoettgens]

2. For the submodules (Generic and PrettyPrinting) there is currently a mix of exporting their functions from the submodule and importing into the main AbstractAlgebra module. Which of the two is the one to use?

Maybe I am missing something in your question, but I don't think the two are interchangeable in general?

• if foo is defined before module Generic is loaded, then Generic must import it
• if foo is only defined *after module Generic, then Generic cannot import it; and if code outside Generic is supposed to use foo or even install methods for it, then Generic but must export it

I am both times talking about the flow Generic -> AbstractAlgebra. Sometimes, Generic exports stuff to AbstractAlgebra and sometimes AbstractAlgebra imports stuff from Generic.

[fingolfin]

Maybe wait a bit with this, as the GroupsCore PR is getting closer to being finished and it'll touch the exports a bit, too, so there are conflicts

[fingolfin]

Ah, so I indeed misunderstood, sorry. Well, we never do using .Generic, do we? So I would expect all those export statements in Generic to have no effect?

[lgoettgens]

Ah, so I indeed misunderstood, sorry. Well, we never do using .Generic, do we? So I would expect all those export statements in Generic to have no effect?

Ah true... So I will delete them (without semantical change)

[fingolfin]

@lgoettgens this can in principle be updated and merged, right? Nothing I should do, is there?

I realize you may have more important things to do right now, I just want to make sure that I am not unwittingly the blocker :-).

[lgoettgens]

I think there is basically nothing really no to do here (apart from merging the two export lists). But as long as this is not compatible with Oscar master, I am afraid to break things due to the OscarCI not running. So I would only start to work on this after oscar-system/Oscar.jl#3231