Messy function names

[SoongNoonien]

Most function (and type) names are really messy (e.g. nrclasses, nrchars, chardeg, printinfotab, ...). Some of this is due to the heritage of the project. Julia is very different from Maple so the way one interacts with the ported library is different already and when things like #29 will be implemented this will be even more so.

So is it even desirable to keep the messy names?

[fingolfin]

We want new names in compliance with OSCAR naming guidelines, and in some cases "no names" at all. E.g. I imagine several of the print* function will turn into show methods for dedicated objects.

[fingolfin]

However, if we rename things, we definitely should add a table in the manual that translates the CHEVIE names to our names (or rather: translates CHEVIE constructs to our equivalents, which in some cases may be far more different than just a new name).

[fingolfin]

For functions that return a number of something, there is an ongoing standardization effort, see oscar-system/Oscar.jl#3305 for the discussion there and the proposed change to the docs (which as I write this is not fully settled as far as I know... but I've been out of the loop due to illness).

[SoongNoonien]

Maybe this can also be helpful here: https://docs.julialang.org/en/v1/base/base/#Base.@deprecate

[fingolfin]

Some ideas

• nrclasses -> number_of_conjugacy_classes (and existing OSCAR method, so should be imported and re-exported)
• nrchars -> number_of_characters
• nrirrchars -> number_of_characters (same name seems sensible here)
• classtypes -> number_of_conjugacy_class_types
• centord -> centralizer_order
• Perhaps also offer number_of_character_types as an alias for length on a table, for symmetry?

[SoongNoonien]

I looked at the naming guidelines again and this is a list of violations (including suggestions) is still see.

• chartypeid -> character_type_index
• genchartab -> generic_character_table
• greenfuntab -> green_function_table
• lincomb -> linear_combination
• nesum -> geometric_sum
• nrparams -> number_of_parameters
• setcongruence -> add_congruence (we don't just set it anymore)
• specclassparam! -> specialize (when we have something like Add a generic class type #168

Maybe we should also replace param by parameter in all names. Also the type names Table, CharTable and SimpleCharTable could be improved to be more in line with the generic character types.

[fingolfin]

add_congruence IMHO has an unfortunate parallel with add!. Perhaps apply_congruence ?

[fingolfin]

I also think geometric_sum might be misleading. I suggest we keep it at nesum for now but stop exporting it.

The rest sounds good to me.

[fingolfin]

We just discussed to also rename params to parameters (and then nrparams not to number_of_params but to number_of_parameters)

[SoongNoonien]

add_congruence IMHO has an unfortunate parallel with add!. Perhaps apply_congruence ?

I see that add might be confusing. I've decided to go with the minimal change set_congruence just to be compatible with the naming convention.