The big renaming

[fingolfin]

Companion to Nemocas/AbstractAlgebra.jl#1267, thofma/Hecke.jl#977, oscar-system/Oscar.jl#1972

This is WIP on the big type renaming, see also https://hackmd.io/0hrBHIUrRZG23xiZZ0NCEA?both for our notes (these are partially outdated and misleading, we are working on that).

One issue with this PR is that we rename

• FqDefaultPolyRing => FqPolyRing
• FqPolyRing => FqPolyRepPolyRing

So the name FqPolyRing is both an old and a new type name, albeit with different meanings, which is unfortunate.

Actually, this could be avoided because FqPolyRing is not the final name we want anyway... Right now we do these renamings:

• FqDefaultFiniteField => FqField
• FqDefaultMatSpace => FqMatrixSpace
• FqDefaultMPolyRing => FqMPolyRing
• FqDefaultPolyRing => FqPolyRing
  but we really would prefer to just call this FinField, FinFieldMatrixSpace, etc. (or perhaps FiniteField, ...?) but FinField is already an abstract type in AbstractAlgebra... We could rename that, or just re-use the name (by not importing FinField from AA into Nemo), but all of these involve further discussions and decisions which is why I did not yet attempt this here.

Also missing are the various SeriesRings/SeriesElem. I'll work on those tomorrow

And of course there are more things to be done in AA, Oscar, Hecke

TODOs (either in this PR or a follow up):

• also rename _series types
• consider updating filenames (such as fmpz.jl), OR if we keep them, ensure we reference them correctly in code and docs
• update documentation (e.g. docs/src/developer/introduction.md:58) with a table translating old "Flint names" like fmpz to new "Nemo names" like ZZRingElem
• add docstrings to all types that
  - explain what the type represents
  - mentions Flint names, if applicable
  - gives an example how to create an instance (ideally as a jldoctest)
• ...

[fingolfin]

Also, we wanted to rename arb to RealFieldElem and more arb/acb renaming, but then discovered that there is already RealElem which seems to be almost identical to arb except for the parents, and so maybe we need some further discussion, perhaps with @thofma ?

[thofma]

I merged #1367 yesterday, because it is related.

To quote from #1367 (comment)

I don't want to hear any discussions about the names. If they need to be adjusted, it can be done during the "big rename"

Ideally a user will never see an arb/acb again, so I would leave them as they are now. Rename the RealElem etc. as much as you want. I am also happy to discuss this.

[codecov]

Codecov Report

Merging #1376 (06952bc) into master (c152bcb) will increase coverage by 0.02%.
The diff coverage is 78.77%.

@@            Coverage Diff             @@
##           master    #1376      +/-   ##
==========================================
+ Coverage   88.43%   88.45%   +0.02%     
==========================================
  Files          88       88              
  Lines       34327    34327              
==========================================
+ Hits        30356    30363       +7     
+ Misses       3971     3964       -7     

Impacted Files	Coverage Δ
src/Nemo.jl	27.48% <ø> (ø)
src/ambiguities.jl	0.00% <0.00%> (ø)
src/calcium/CalciumTypes.jl	100.00% <ø> (ø)
src/flint/FlintTypes.jl	94.81% <ø> (ø)
src/flint/flint_puiseux_series.jl	81.49% <ø> (ø)
src/flint/fmpq_mpoly.jl	86.29% <ø> (ø)
src/flint/fmpq_poly.jl	94.73% <ø> (ø)
src/flint/fmpq_rel_series.jl	94.40% <ø> (ø)
src/flint/fmpz.jl	92.81% <ø> (ø)
src/flint/fmpz_abs_series.jl	94.84% <ø> (ø)
... and 79 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[fingolfin]

I merged #1367 yesterday, because it is related.

Thank you, I hadn't noticed, and will read up there now.

To quote from #1367 (comment)

I don't want to hear any discussions about the names. If they need to be adjusted, it can be done during the "big rename"

Oh sure -- I didn't mean to complain about the names there (or anything, for that matter), it was just a bit of confusion yesterday when we discovered RealElem vs. arb and where unsure how to continue.

But now this seems clearer:

Ideally a user will ever see an arb/acb again, so I would leave them as they are now. Rename the RealElem etc. as much as you want. I am also happy to discuss this.

So basically we use RealElem (possibly renaming it to RealFieldElem, etc., etc and ignore arb and acb and friends. And then in Oscar.jl, I think the only places referencing them are in the serialization code, so I guess that code should be changed to use RealElem etc. (And for Hecke, I am sure you already have a plan, so we'll not touch it there)

[thofma]

Yes, that sounds good.

[fingolfin]

I've now renamed RealElem to RealFieldElem and ComplexElem to ComplexFieldElem.

Alas, there is already a type RealFieldElem in Hecke, for a completely different purpose, so I'll have to rename that first now ...

[thofma]

there is a reason it is big renaming and not just renaming :)

[thofma]

Is squash fine?

[fingolfin]

The branch protection rules are confused by the fact that we are not testing against the master branch of upstream, but rather mh/rename. So we can't use automerge sigh

[fingolfin]

ARGH I accidentally rebased instead of a merge. I'll fix it