#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 nbruin):
Nicholas has explained his original intent to a large degree in a post
above and I mostly agree with him, except on one place. Apparently, in his
model every category is constructed from a supercategory and an axiom. In
that case there is no need for guessing data: all the data is there when
the category gets constructed.
Apparently some categories do not get constructed explicitly from a
supercategory and an axiom. Instead, the system splits the `__name__` into
pieces and uses part as a name for an axiom and another part as name for
the supercategory. I guess that this seems a convenient shortcut because
most of those categories are defined by literal source code. I think it's
crossing a line. Nowhere else in Python does the makeup of a name
determine the inheritance of properties (which eventually categories will
lead to). As Thierry points out, it's a heuristic one can avoid, but I
think it departs so much from what Python normally does that it will
frequently lead to confusion. I think you should look for a cleaner
paradigm to express these relations concisely, and now is the time to get
it right. It will be more painful to change it afterwards.
It doesn't sound to me like the category information forms a database in
the sense of a bunch of tables filled with rows and columns. To me it
seems closer to a (rooted?) tree, with edged labelled by axioms. Python
has syntax to express rooted trees: inheritance. The only thing missing is
the label. That can be replaced by a class attribute, simply set to a
string. There is a small amount of boilerplate involved with writing
classes, e.g., one usually has to write `def __init__(self):`. Writing a
single line `axiom = "Finite"` can be considered acceptable boilerplate in
my opinion and removes all guessing. Do you think that having to write
that "Finite" is redundancy because "Finite" already occurs in the
`__name__`? In that case I disagree: everywhere in python people are free
to choose names that they think are most informative (avoiding collisions
and key words), regardless of semantics of the code.
Replying to [comment:311 SimonKing]:
> So, questions to Nils:
> - Do you intend to handcode everything? Then you need to cover many
cases.
I may misunderstand what is required in the process, but at the moment I
think "yes". If an axiom is a required property for a Category then it
needs to be supplied somewhere, not derived by chopping a part of a
`__name__`.
> - Do you intend to put `PermutationGroups().Finite()` into code that is
executed at startup time, and similarly for ''all'' other categories with
axiom? Then, the startup time would likely to increase, and it would not
be less work than the other way to handcode the construction.
You do not make that sound attractive. I don't know what that code would
do, so I was not intending to put that anywhere.
> - Do you intend to change the logic totally? This would mean to re-write
Nicolas patch from scratch.
If the present patch unavoidably leads to convoluted constructs that
that's a strong indication that the design is flawed. In that case it
might be advisable to either redesign or carefully argue what the current
design is and indicate why the nasty bits are really unavoidable.
This is infrastructure. We'll be living with this for a ''long'' time (see
coercion framework). It's worth trying to get it right.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:326>
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.
