#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 nthiery):
Replying to [comment:382 nbruin]:
> 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.
+1
> 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.
It's not a label. Cs() inherits from the Sets category a ``Finite``
method, and it can complement this method with extra data (here a
mixin class) in the form of a class attribute ``Cs.Finite``. The fact
that ``Cs.Finite`` *complements* the ``Finite`` method rather than
*overriding* is not unnatural: that's what sequences of ``super``
calls are usually about.
> 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).
Note quite since the definition of an axiom is local to a category and
its super categories. For example, the category of Modules defines an
axiom "Graded", and this fixes the semantic of Cs.Graded for every
subcategory of Modules, but no more. That's no different from usual
hierarchy of classes: if a class defines (or declares) an attribute or
method with a given name, this fixes the semantic of that name for all
subclasses.
Therefore I don't think we need to take any more specific step than if
we were implementing usual hierarchies of classes.
Of course, I agree that it's good for consistency to promote the
convention that axioms and functorial constructions should start with
a capital. It gives a hint that ``Cs().A()`` is going to construct a
category.
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:385>
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.
