The Core Packages and the Idea behind their Splitting I will try to explain the idea behind splitting the 6 core packages: &homalg; &Modules; &HomalgToCAS; &IO_ForHomalg; &RingsForHomalg; &ExamplesForHomalg;
The 6=2+4 split The following is an attempt to explain the 6=2+4 split. Logically independent The package &homalg; is logically independent from all other packages in the project. And among the six core packages it is together with &Modules; the only package that has to do with mathematics. The remaining four packages are of technical nature. More precisely, &homalg; is a stand alone package, that offers abstract homological constructions for computable Abelian categories. But since the ring of integers (at least up till now) is the only ring which for the purposes of homological algebra is sufficiently supported in &GAP; (&see; ), &Modules; can put the above mentioned abstract constructions into action only for the ring of integers and by generic (but of course non-efficient) methods for any of its residue class rings (Simon Görtzen's package &Gauss; adds the missing sufficient support for &ZZ;/p^n and &QQ; to &GAP; and his other package &GaussForHomalg; makes this support visible to &Modules;). Black boxes The package &Modules; uses rings and matrices over these rings as a black box, enabling other packages to abuse &homalg; to compute over rings other than the ring of integers by simply providing the appropriate black boxes. And whether these rings and matrices are inside or outside &GAP; is not at all the concern of &homalg;. Even the &GAP; representation for external rings, external ring elements, and external matrices are declared in the package &HomalgToCAS; and not in homalg. Summing up One of the main concepts of the &homalg; project is that high level and low level computations in homological algebra can and should be separated. So splitting &homalg; from the remaining 4 core packages is just emphasizing this concept. Moreover, &homalg; is up till now by far the biggest package in the project and will probably keep growing by supporting more basic homological constructions, whereas the other 4 packages will remain stable over longer time intervals.
The 4=1+1+1+1 split The following is meant to justify the remaining 4=1+1+1+1 split. &HomalgToCAS; The package &HomalgToCAS; (which needs the &homalg; package) includes all what is needed to let the black boxes used by &homalg; reside in external computer algebra systems. So as mentioned above, &HomalgToCAS; is the right place to declare the three &GAP; representations external rings, external ring elements, and external matrices. Still, &HomalgToCAS; is independent from the external computer algebra system with which &GAP; will communicate and independent of how this communication physically looks like. &IO_ForHomalg; and Alternatives The package &IO_ForHomalg; (which needs &HomalgToCAS;) allows &GAP; to communicate via I/O-streams with computer algebra systems that come with a terminal interface. &IO_ForHomalg; uses Max Neunhöffer's &IO; package, yet it is independent from the specific computer algebra system, as long as the latter provides a terminal interface. Splitting &IO_ForHomalg; from &HomalgToCAS; gives the freedom to replace the former by another package that lets &GAP; communicate with an external system using a different technology. So making &IO_ForHomalg; a package of its own makes it clear for developers of a new communication method which package of the &homalg; project has to be imitated/replaced. To be concrete, Thomas Bächler wrote a package called &MapleForHomalg; that enables &GAP; to communicate with &Maple; without the need for a terminal interface. &RingsForHomalg; The package &RingsForHomalg; (which needs &HomalgToCAS;) provides the details of the black boxes &homalg; relies on. The details of the black boxes of course depend on the external computer algebra system (&Singular;, &MAGMA;, &Macaulay2;, &Maple;, &Sage;, ...), but are independent from the way the communication takes place. So it can be used either with &IO_ForHomalg;, with &MapleForHomalg;, or with any future communication package. Your own &RingsForHomalg; If someone needs to support a ring in some computer algebra system that &GAP; can already communicate with, but where the ring is not supported by &RingsForHomalg; yet, she or he needs to imitate/replace &RingsForHomalg; (as Simon Görtzen did with his &GaussForHomalg;, where the computer algebra system was &GAP; itself, extended by his package &Gauss;). Any substitute for &RingsForHomalg; -- as it only needs &HomalgToCAS; -- will again be independent from the way how &GAP; communicates with the computer algebra system that hosts the ring. This should encourage people to link more external systems to &homalg; without being forced to join the development of the package &RingsForHomalg;. They can simply write their own package and get the full credit for it. &ExamplesForHomalg; The package &ExamplesForHomalg; (which needs &RingsForHomalg;) contains example scripts over various rings that are written in a universal way, i.e. independent from the system that hosts the rings. These examples cannot be part of the &homalg; package as they are defined over rings that &GAP; does not support. The package &ExamplesForHomalg; is meant to be the package where anyone can contribute interesting examples using &homalg; without necessarily contributing to the code of any of the remaining core packages. Documentation Splitting the core packages is part of documenting the project. The complete manuals of the &homalg; and &ExamplesForHomalg; packages (maybe apart from the appendices) can then be free from any non-mathematical technicalities the average user is not interested in. A documentation of the three packages &HomalgToCAS;, &IO_ForHomalg;, and &RingsForHomalg; will be rather technical and of interest mainly for developers. Crediting Everyone is encouraged to contribute to the &homalg; project. The project follows the philosophy of avoiding huge monolithic packages and splitting unrelated tasks. This should enable contributers to write their own packages (building on other existing packages) and getting the full credit for their work, which can then be easily distinguished from the work of others. Stability A huge monolithic package can never stabilize, even though parts of it will stay frozen for a long period of time. The splitting makes it likely that parts of the project together with their documentation quickly reach a stable state.