#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
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-doc- | Commit:
distributive | ece5c973b179319616ff99c3f2ddfd2b6dfcdfd4
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by vbraun):
Replying to [comment:558 nthiery]:
> That's precisely my point. Similarly, if two independent categories Cs
> and Ds define an axiom with the same name but different semantic, and
> someone creates a subcategory Es of both Cs and Ds, then there is no
> *accidental* clash.
And what is the alternative in the category framework to creating a
subcategory of both C and D? In Python it is clear that multiple
inheritance is not the answer to everything, and you can e.g. use object
composition to combine classes as an alternative. But here I don't see a
way to avoid a name conflict, hence in the above situations the names
truly do clash and the poor sap who wants to combine C and D for the first
time is thoroughly screwed.
If there were some fundamental reason why we really need to have
potentially clashing axiom names then I wouldn't even mind. But really
this is all just to support your special subcategory syntax. As I've
demonstrated you can even have subclass syntax without requiring special
names. So why introduce this totally unnecessary trap for the unwary? To
save one line of code required to make the axiom explict?
> Good. I worked hard so that we could have this *pleasant* surprise :-)
Except my sentiment in comment:380 was more along the lines of "if Guido
van Rossum were dead then he'd be turning in his grave right now" ;-)
Anyways, coming back to constructive suggestions: Lets just get rid of the
subclass syntax. Really, that has no business on this ticket which is
supposed to be the initial implementation of axioms. First you need to
have a solid implementation of the axioms and relations, then you can
think about beautifying the syntax. This just amounts to a lot of
dedenting, inserting `_base_category_class_and_axiom` in the right places,
and deleting some metaclass magic. Since "manual" construction of
category-with-axioms is supposed to be always possible we also wouldn't
have to publicize a programming interface that is going to be yanked away
in the future. Once we are happy with the implementation we can think
about providing a more concise syntax in a future ticket. But IMHO we
should focus more on the implementation first, e.g. find ways to not do a
potentially-infinite recursive computation on startup etc.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:560>
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.
