#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, | 8045aa4a4b7ada735b3eb6055382f9b341a39f1e
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:380 vbraun]:
> Axioms are at the end of the day the analog of mixins in the category
framework, and as such implemented as classes. Just return the classes.
This should be obvious.
I'm not entirely sure this is true presently. While `Groups.Finite` points
to a
class (category) `FiniteGroups` (or really just at the class named
`Groups.Finite` if written as a nested class), the class `Sets.Finite` is
also
automatically picked up, and if I'm not mistaken that's one of the
features of
axioms: if they can, they get applied to supercategories as well. The
class
`FiniteSets` and the class `FiniteGroups` are quite probably distinct
classes,
so there is no single class that symbolizes the `Finite` axiom, yet it is
relevant that `FiniteGroups` resp. `FiniteSets` are obtained from `Groups`
resp.
`Sets` by applying the ''same'' axiom. The label that signifies this is
currently the string `"Finite"`. From an implementation point of view I
think
it's confusing to abuse the class type `__dict__` to document this fact,
but
Nicholas does illustrate how the abuse leads to easy to write classes.
Essentially, Nicholas has selected a bunch of special method names (such
as
dundermethods `__len__`, `__get__` etc) and blessed them to be "axioms",
which
receive special treatment: If a category implements one of those then this
axiom
can be "applied" to this category. It does mean the documentation should
have an
exhaustive list of what method names are considered `axioms` and
introducing new
axioms would be subject to name clash warnings (we wouldn't want to break
code
out there that already gives a non-axiom meaning to an attribute).
I think that if we're staying with this pattern, we should announce some
rule:
on categories, any method name starting with a capital is in principle
reserved
to be used as an axiom or functorial construction. We should probably also
include some guidelines how users should go about implementing their own
non-library axioms in a way that is likely to work with future versions,
or
declare that such a thing is not guaranteed (meaning Categories do not
implement
an "open protocol" but are entirely meant to be internals of sage).
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:382>
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.
