Dear Sage and Sage-Combinat developers,
Up to now, the focus in the port of the combinatorics stuff from
MuPAD-Combinat (and others) to Sage has been on the superficial
feature set. This was an essential step to make Sage usable enough for
combinatorics to get users and developers on board (thanks again to
Mike for the amazing job he did there).
Now, with the fundamentals progressively coming in (categories, basic
data structures, species, integer lists generated lexicographically,
LattE) the focus is now shifting. It is becoming essential to refactor
the existing code to cleanly use those fundamentals before growing too
much further. I very much hope that the refactoring process should
allow for discarding at least one half of the code while
simultaneously increasing the flexibility and thus the feature set.
There is a strategical balance to achieve between maintaining
reasonnable backward compatibility while not empedding the refactoring
process. The purpose of this e-mail is to get feedback from *you* on
this topic. Who is using the combinatorics stuff? Who has code that
depends on it? How hard would it be to update that code?
My *personal* point of view is that, at the current stage, the
combinatorics stuff is still at its infancy, and refactoring should
get the top priority. As such, I would put the following policy (until
things stabilize seriously, probably in a couple months, maybe one year):
- Maintain backward compatibility whenever possible without hassle.
- When maintaining backward compatibility would require ugly
circumvolutions, do not do it by default. Instead, wait for someone
to actually complain, and negotiate on a case by case basis
(with an implicit promise of providing a fix very quickly when needed).
That being said, the debate is fully open!
Typical issues I do expect:
(1) name changes for some methods / ...
(2) data structure/class changes for elements and parents
(3) unpickling of objects pickled on older versions of Sage
Most of the time, (1) should be easy to do while keeping backward
compatibility with aliases.
If encapsulation was done properly (2) should be relatively
transparent to the user, except for (3).
(3) can become really tricky. Does anyone rely heavily on a currentl
picklejar full of combinatorial elements and/or parents? That is who
would be seriously anoyed if such a picklejar could not be reloaded
into Sage in the future?
Note I: (3) is distinct from the issue of some of our objects which
are currently not picklable. This I consider as a bug that should
eventually be fixed.
Note II: to reduce issues of type (3) in the future, it could be a
good idea to setup as default policy for parents to be pickled "by
construction", and not "by data structure". E.g. the parent P =
Partitions(3, min_part = 2) would be unpickled by calling again
Partitions with 3, min_part = 2 as arguments. This behaviour could
typically be achieved by implementing construction() and using it for
pickling. This has the side advantage of playing better with unique
representation.
Best regards,
Nicolas
--
Nicolas M. Thiéry "Isil" <[email protected]>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
