#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963 | Commit:
Dependencies: #11224, #8327, | 478de48553d203516cddb47e0cb89c34ccc210ee
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Thanks guys for bringing in your different perspective!
A couple comments:
- We should leave the database discussion aside for now. It's just
going to pollute that thread which is already too long.
- Nils is right in that the category *code* is indeed structured as a
tree. Of course, the inheritance diagram between the categories
forms an acyclic digraph.
- The guessing is just about allowing for the shorthand
{{{FiniteDimensionalAlgebras(QQ) -> Algebras(QQ).FiniteDimensional()}}}
Those shorthands are mostly used interactively or for backward
compatibility.
- The guessing does not prevent from using any name you like for your
class. But if you adhere to the standards, which is what you would
do naturally anyway most of the time, you get rewarded by some
syntactic sugar and don't have to write down redundant
information. I like the idea of encouraging people to follow the
standards.
- In case there is a typo in the class name, you get an explicit error
the first time you try to create the category. So, assuming the
black magic is now reasonably robust (I believe so, but ...), the
issues should only pop up when creating a new category, and thus be
well localized and easy to debug.
- By setting explicitly _base_category_and_axiom, you are putting in
information which is redundant with the reverse link from the base
category. For the above example, here are the two pieces of
information:
In Algebras:
{{{
FiniteDimensional =
LazyImport('sage.categories.finite_dimensional_algebras',
'FiniteDimensionalAlgebras')
}}}
In FiniteDimensionalAlgebras:
{{{
_base_category_and_axiom = [Algebras, "FiniteDimensional"]
}}}
This violates the single point of truth and opens the door for
inconsistent information. It also makes restructuring the code a
tiny bit be more brittle. Granted, it's not so bad since, in
principle, any such inconsistency will be detected and barked about
at runtime.
- The act of not specifying _base_category_and_axiom is actually a
statement: ``this category is following the naming standards''. This
statement is used in the name building for category objects (see
_repr_object_names). Getting nice names for category objects is an
important feature that we will have to support one way or the other.
- For the record, there is already some name mangling occurring in the
Sage code, e.g. for unpickling instances of nested classes, or for
compiling the documentation thereof with Sphinx. And of course in
repr for constructing the names of the objects of the categories;
but I agree that the latter is not as touchy since this only affects
the output, not the semantic.
Altogether, I really don't like adding this redundant information
everywhere. It feels to me as spreading dirt over my carefully crafted
idioms :-) But I understand your being conservative after the bad bug
that hit us. And we need to move forward and get this done. If you
*really* can't stand this guessing, go ahead, add the redundant
information everywhere this is needed, and fix the implementation of
_repr_object_names accordingly.
If instead you have a protocol in mind that avoids this redundant
information without doing name mangling and while leaving the same
flexibility in terms of code organization (in particular supporting to
implement a category with axioms either as a nested class or in a
separate file, typically lazy imported), I am all ear! But I converged
to this protocol after three years of practical usage. I may of course
have missed something obvious but don't foresee myself finding some
better protocol in the coming days.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:330>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
