On Mon, Nov 26, 2012 at 6:34 AM, Simon King <simon.k...@uni-jena.de> wrote: > Dear Paul-Olivier, > > On 2012-11-26, Paul-Olivier Dehaye <pauloliv...@gmail.com> wrote: >> My understanding of aspect-oriented programming in general: encourages the >> developer to realize that there are several concerns that will be present >> in a large project, and to organize the project in such a way to minimize, >> at any location in the code, the number of concerns whose concrete >> implementation is relevant. >> ... Identifying these concerns >> (which are just fuzzy words and not programming constructs) and structuring >> the code (/concern1, /concern2, ...) around them helps guide people to the >> relevant places in the code
Many of these aspects (e.g. hashing) don't seem to be important enough to merit a top-level directory, but certainly a top level "utils" directory could be a good place to stick them. (Misc is somewhat used in this way). > My impression is that Sage's directory structure tries to address different > concerns (meaning here: different mathematical topics). Do you think > that the present directory structure does not succeed to keep different > concerns apart? The current structure is more grown then planned, but I think it makes sense to structure code topically as it is now. > Sure, coercion is everywhere, and so it can easily be that a memory leak > shows up in elliptic curves but is ultimately caused by caching data for > coercion. > >> Don't confuse a plan with more docs buried in the code. There is >> documentation everywhere that explains what that particular class or method >> is doing, but nothing at a higher level: where is sage's outline as it >> stands? (the first part of "State of Sage" speech?). > > Ideally, every concern of Sage (according to the directory structure, it > is categories, coding, combinat, ..., structure, symbolic, tensor) > should have a top-level documentation, in addition to the documentation > of each class/method. I am actually not sure to what extent such > top-level documentation exists. > >> - Separate the actual Categories framework as it currently exists into two >> parts. The first would be a "Mathematical abstraction" layer, where very >> abstract mathematical information is implemented. >> - Force the mathematical developer to think in terms of mathematics first, >> i.e. require a category to be specified in order to be able to construct a >> Parent. > > +1. But how to enforce it? Some people (including myself) occasionally try > to shift old code to the new category and coercion model. Would it be > enough to ask the reviewers of a patch to take care that the category of any > *new* parent is duely defined? Or should one make doctests fail on > purpose, if a parent is not properly put into a category, to enforce its use? > >> - Doing it this way helps us automatically create a lot of tests first, >> before anything concrete has been written (developer needs not be concerned >> about writing the tests, they are magically created). > > By the way: I think automated tests are an important aspect of our category > framework, and my impression is that developers should use it more > often! +1 >> - Specify the coercions that should exist at the "Mathematical abstraction" >> level. >> - Specify for each new Parent how to coerce from the Category down to the >> Parent. > > Could you elaborate a bit more? What does "to coerce from the category > down to the parent" mean, and *what* coercions should exists at the > mathematical abstraction level? > > There are of course tools to define coercions. > >> - All the coercions and tests are automatically generated from this >> information. > > Well, coercions *are* automatically generated (by some kind of > backtracking algorithm) from the output of the _coerce_map_from_ methods. > >> (PS: it might already be possible to use the coercion model in this way. If >> so, please please please point me to where it is explained. In any case, my >> point stands as I was not able to find this despite searching.) > > A while ago, I have created a public worksheet on "how to implement > basic algebraic structures in Sage", using category framework and coercion. > I think at some point it was supposed to become part of the > documentation, but I think we lost momentum. I see http://combinat.sagemath.org/doc/thematic_tutorials/tutorial-implementing-algebraic-structures.html , is this sitting in a combinat queue somewhere? I think one issue is that when people go to define a new parent, they look at integer or polynomials, which are (1) crufty and (2) optimized beyond what is needed for less basic types (e.g. if your arithmetic takes microseconds rather then nanoseconds, it's just not worth optimizing c function calls). >> Once we agree on the desired modularity we need in the code, we can decide >> on how to modify what we have to achieve separation of concern. In Python, >> the answer would most likely be "with decorators and metaclasses" (indeed, >> as you pointed out, cached_function and so on isolate one aspect of a >> function). > > Both decorators and metaclasses are used in Sage. Note one problem, though: > If you want to create a new class inheriting from classes with distinct > metaclasses, then Python complains. > > I had experimental code to overcome that problem, namely by using > meta-metaclasses that dynamically create a new common metaclass out of any > list of metaclasses. Hence, if A and B are classes with metaclasses MA and > MB, then you can define > class C(A,B) > so that C gets a dynamically created metaclass MC that is a sub-class of > both MA and MB. The idea is that both MA and MB (which *are* > metaclasses) have a common meta-metaclass MM, and MM is able to create a > new metaclass MC out of MA and MB. > > In that way, you could have metaclasses for different purposes, and can > freely combine them: You want a class that is pickled by construction > and whose instances are cached? Then simply combine > DynamicMetaclass and ClasscallMetaclass. No need to separately/manually > define DynamicClasscallMetaclass anymore - the meta-metaclass would do > that for you. > > But it seems people found the idea of meta-metaclasses a bit confusing... If most people don't have to touch tem directly, I say lets resurect this. On this note, originally there was an effort to share common code/concerns purely with the OO model. Of course this fails on multiple levels (in particular when the *category* of an object depended on its data rather than its implementation, e.g. should Z/nZ extend Field? Should R[x] extend UFD, should Matrices[n,m] extend Ring?), which left things in a bad state as well as leaving a bad taste in people mouths. Metaclasses and decorators can greatly improve this situation, and the current category framework makes large strides in this direction. >> - "This will slow down the one class I am using a lot": Not if it's done >> right. In fact, if it's done very right it would speed up considerably >> everything, > > +1. For very basic types, decorators and metaclasses can be a performance concern. And for some things (e.g. the coercion arithmetic support) the framework needs to be fast enough to handle your basic ring arithmetic without overhead (ties in to point (2) above). Unfortunately C/Cython isn't as flexible and dynamic as pure Python (some of which can be overcome by improving Cython, but some is intrinsic to early, static binding). But most of the time, I'd say yes. > One example: One can write a FastHashMetaclass. If you then take a > python class A that has a `__hash__` method, and apply to A the > FastHashMetaclass, then A.__hash__ would automatically be turned into a > fast Cython hash that moreover is cached (so that the hash value does > not need to be computed repeatedly). This is a very good example. From a feasibility standpoint, I think starting with concrete examples and implementing them one at a time is the only way it will happen. Trying to come up with a grand plan to solve everything will likely be too much work to coordinate and accomplish without dedicated resources. - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
