Towards GAP 5 (with minimal breakage) ?

[fingolfin]

During GAP Days we discussed the possibility of making a "GAP 5" release. Mind you, this was just a discussion, and possibilities, and nothing has been decided yet.

One motivation for such a move is purely from a "marketing" point of view. E.g. versions like "4.15" are confusing for many people (I've heard it being called "version 4-1-5").

Another is a chance to perform some mild, well-documented, low-impact breaking changes. The two examples that came up so far:

• possibly removing the "package namespaces" which adds complications in kernel and library but in practice is rarely used and has many usability issues, while not really solving the problems it was presumably meant to solve
  • only, a handful of distributed packages use this, including these (I don't claim completeness), most of which can be trivially changed away from using it:
    • autpgrp
    • classicpres (substantial user of @)
    • float
    • fr (substantial user of @)
    • liepring
    • modisom
    • polycyclic
    • rds
    • repndecomp (substantial user of @)
    • wedderga
    • zeromqinterface
• removing support for the ability to enter floating point literal starting with . -- that is, entering a literal like .0 instead of 0.0
  • see Remove support for float literals starting with a period [DO NOT MERGE] #3280 for details
  • this only affects very few packages, possibly at most 1, and likely the private code of very few people
• remove support for DeclareAutoreadableVariables / AUTO
  • atlasrep
  • browse
  • ctbllib
  • liealgdb
  • smallsemi
  • sonata

In each case, the proposal would not be to just rip these things out immediately, but rather multi-stage

• first, mark these features as deprecated, and notify package authors
• work towards all packages have stopped using a feature
• modify GAP to issue warnings when these features are used
• and then after an additional grace period (say, one full GAP release cycle) we can consider really removing the feature

In all cases, such changes must be clearly communicated to users, the release announcement should mention them, there should be a page with instructions how to deal with them if one is affected.

And while we make no promises to deal with undeposited packages, I'd be interested to also having a look at those (see list at https://gap-packages.github.io for some I know of) and seeing how any of this affects them, if at all, and possibly helping them to adjust.

Anyway, food for thought.

[hulpke]

I really liked the concept of Name spaces, in particular in starting with the translation of Magma Code. It allows for packages to use their own, descriptive, names, even if they clash with GAP globals.

They might be a bit clumsy, but is there an inherent problem they cause?

[ChrisJefferson]

Just a suggestion -- I've found myself increasingly just using records (for example, I put functions in vole into a record called Vole, like Vole.Stabilizer). Everything seems to work fine (tab completion, GAP doc).

[james-d-mitchell]

Just a suggestion -- I've found myself increasingly just using records (for example, I put functions in vole into a record called Vole, like Vole.Stabilizer). Everything seems to work fine (tab completion, GAP doc).

Same for me. I think the concept of namespaces is a useful one but GAP namespaces as currently implemented are not.

[fingolfin]

Added proposal to remove DeclareAutoreadableVariables / AUTO