I am confused about what to do. Everyone seems to be assuming that one of Volker's or Nicolas' approaches must be right. It might very well be that both approaches are suboptimal compared to a third. Still, Nicolas' has the merit to be implemented.
Let me explain: I support Nicolas' initiative and do very much think this is a feature we want in sage. I have concerns with Nicolas' nested classes approach but recognize that it has the merit of being the only one implemented (and used already!). My opinion is that all the objective criteria for a patch have been passed (except for some regression on legacy code, which does not seem to be the core of Volker's objections) and that only fairly subjective concerns are left (paraphrase: "it's confusing to a python developer to have nested classes!"). I also have concerns with Volker's approach. I have my own alternative approach to suggest. I am not willing to devote the time to implement my own alternative (just like Volker is not willing to implement his). I am willing to review any patch submitted by Volker and suggest improvements (these are likely to require substantial work on his part). I am *definitely* not trying to be obstructionist but am afraid that in this case the review process for patches is unclearly defined, and just aping the behaviour of others by me would lead to total stalemate. At this stage I better outline my own solution so as to open it to more criticism from everyone (more fun!). As I see it, both Nicolas' and Volker's suggestions have the shortcoming that they require a one-time decision now of how to make purely mathematical information fit into python's syntax (object for an axiom versus nested classes). This also prevents any further reuse (short of python introspection of live objects or static analysis of the code) of this formalised-as-code purely mathematical information into any other system, be it the LMFDB, the combinatorial statistics finder, the atlas of categories, another CAS or any other mathematicians' collaborative efforts. Instead, I would advocate using a declarative domain specific language built for semi-formalizing mathematics. Such a language was developed as part of a PhD thesis (Florian Rabe), and is called MMT. It tries to precisely address the needs of a community of mathematicians trying to formalise some part of mathematics. In fact (and very importantly) you don't need to formalise from the ground up. You can just formalise parts of math (i.e. "a finite group has order a prime power", even though you never defined what a group was). This is meant to be used collaboratively, and in fact meant to be used for the whole math community at once in a distributed fashion. You should think of it as "OpenMath (re)done right". One could argue that this would require sage developers to know two languages (python and MMT), but that would only be true for those who want to implement a truly new category. In fact, if this MMT takes off (and sage might have a role in that), it would allow reuse across use cases, and we would conceivably benefit from the work of others, for instance a database of categories developed by others: http://nforum.mathforge.org/discussion/1754/ Now in my "solution", this declarative language still has to be translated into python code. Of course at that stage mathematicians' interaction and python code have been decoupled, so it would be a pure question of optimisation whether Nicolas or Volker's solution is better. This question would have an entirely objective answer based purely on efficiency. Paul PS: Florian has visited me in Zurich 6 months ago, and is receptive to the idea of using his system as a basis to generate code, even if it was not his original intent. On Tue, Mar 11, 2014 at 10:23 PM, Volker Braun <vbraun.n...@gmail.com>wrote: > On Tuesday, March 11, 2014 8:42:04 PM UTC, Nathann Cohen wrote: >> >> If you want to get this ticket inside of Sage there is an easy way : >> review it. > > > +1 > > also would save me a lot of time > > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-de...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
