<?xml version="1.0" encoding="UTF-8"?>

<!-- 

  Project.xml            homalg package documentation            Mohamed Barakat

         Copyright (C) 2007-2009, Mohamed Barakat, RWTH-Aachen

-->

<Appendix Label="homalg-Project">
<Heading>The Core Packages and the Idea behind their Splitting</Heading>

I will try to explain the idea behind splitting the 6 <E>core packages</E>:

<Enum>
  <Item>&homalg;</Item>
  <Item>&Modules;</Item>
  <Item>&HomalgToCAS;</Item>
  <Item>&IO_ForHomalg;</Item>
  <Item>&RingsForHomalg;</Item>
  <Item>&ExamplesForHomalg;</Item>
</Enum>

<Section Label="6=2+4">
<Heading>The 6=2+4 split</Heading>

The following is an attempt to explain the 6=2+4 split.

<Subsection Label="homalg-independent">
<Heading>Logically independent</Heading>

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 <E>sufficiently supported</E> in
&GAP; (&see; <Ref Sect="Rings supported in a sufficient way"
BookName="Modules"/>), &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 <M>&ZZ;/p^n</M> and <M>&QQ;</M> to &GAP; and his other
package &GaussForHomalg; makes this support visible to &Modules;).

</Subsection>

<Subsection Label="black boxes">
<Heading>Black boxes</Heading>

The package &Modules; uses rings and matrices over these rings as a
black box, enabling other packages to <Q>abuse</Q> &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.

</Subsection>

<Subsection Label="summing up">
<Heading>Summing up</Heading>

One of the main concepts of the &homalg; project is that
high level and low level computations in homological algebra can and
<E>should</E> 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.

</Subsection>

</Section>

<Section Label="4=1+1+1+1">
<Heading>The 4=1+1+1+1 split</Heading>

The following is meant to justify the remaining 4=1+1+1+1 split.

<Subsection Label="HomalgToCAS">
<Heading>&HomalgToCAS;</Heading>

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 <E>and</E>
independent of how this communication physically looks like.

</Subsection>

<Subsection Label="IO_ForHomalg">
<Heading>&IO_ForHomalg; and Alternatives</Heading>

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.

</Subsection>

<Subsection Label="RingsForHomalg">
<Heading>&RingsForHomalg;</Heading>

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.

</Subsection>

<Subsection Label="RingsForHomalg alternatives">
<Heading>Your own &RingsForHomalg;</Heading>

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.

</Subsection>

<Subsection Label="ExamplesForHomalg">
<Heading>&ExamplesForHomalg;</Heading>

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.

</Subsection>

<Subsection Label="Documentation">
<Heading>Documentation</Heading>

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.

</Subsection>

<Subsection Label="Crediting">
<Heading>Crediting</Heading>

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.

</Subsection>

<Subsection Label="Stability">
<Heading>Stability</Heading>

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.

</Subsection>

</Section>

<!-- ############################################################ -->

</Appendix>