#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, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:426 vbraun]:
> I also think that the code on this ticket suffers from a lot of abuse of
lazy imports. They are a useful tool, but they don't absolve you from
thinking about import order of modules.
Quite on the contrary, the code is being thoughtfully specific about
import order. It's being explicit that, e.g., the Magmas category can
be imported and is fully functional without importing
Magmas.Associative (i.e. Semigroups). On the other hand, importing
Semigroups really requires importing Magmas before hand.
> If you do, then you'll run into precisely the kind of hard-to-debug
errors that we found. In particular, lazy imports that you have to resolve
on startup are IMHO a sure sign of code smell.
Oh yes, it smells! But not for the reason you are pointing to. What's
bad is that the corresponding categories are constructed on startup;
and those are constructed because elsewhere in the Sage code some
parents are constructed on startup.
And I precisely **want** to leave those lazy imports in the code so that
it continues to smell and entices people to reduce the number of
parents (and therefore categories) constructed on startup.
Each "at_startup=True" that will be removed will be a measure of progress.
> You are deliberately omitting the other half of the story: If you have
two unrelated classes `C` and `D` then `C.a` and `D.a` are unrelated in
Python. And you are breaking that.
No, I am not!
Ah ah, but now maybe I see the source of the confusion. In order to
make sure that confusion is cleared, let me be very pedestrian, at the
risk of being pedantic (I apologize in advance if I am).
Mathematically speaking, you agree that an axiom *is* naturally tied
to a most basic category, right? That which provides the language
necessary to express the semantic of the axiom.
Expressing this tie in the code is very relevant: it makes the
developer/reader think about the semantic of the axiom and what
structure it is about. And it specifies the context in which the axiom
is defined for (namely all subcategories).
I believe, from experience, that the category is the right place to
express this tie: in particular because looking at the code of the
category exposes what its structure gives as new axioms and
constructions.
With that in mind, I have introduced the following definition in the
documentation: a category *defines* an axiom if it's the most basic
category where the axiom makes sense. This is where the axiom and its
semantic should be specified. A category *implements* an axiom if it
provides a category with axiom that gives additional code for its
objects satisfying the axiom. Of course, a category implementing an
axiom should be a subcategory of that defining that axiom.
This is in exact parallel to classes defining (the semantic of) a
method, respectively implementing a method. Attaching a semantic to a
name in a class/category fixes the semantic of that name for every
subclass/subcategory. And it has the exact same name-clash
limitations. Two independent categories can very well *define* axioms
with the same name but different semantics. But there should be no
axiom with that name in their super categories (otherwise the semantic
of that name would already be fixed). And there should be no common
subcategory.
In practice in Sage, the category that actually defines an axiom might
occasionally be a subcategory of the (mathematically speaking) most
basic category `C`. This can be typically because `C` is not yet
modeled, or for legacy reasons. Or possibly because one later
discovers/wants to implement a better formulation of the semantic of
the axiom that requires less structure to be expressed. Hence the
potential for later having to move up the definition of an
axiom. That's just following a usual move-up-the class hierarchy
refactoring pattern.
Ok, off for lunch!
Cheers,
Nicolas
<sidecomments>
The understatements that the code was written without thinking about
it, or that I am being unfair in my argumentation, are irritating to
me.
</sidecomments>
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:440>
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.
