Yesterday, Steve, Werner, Willem and me discussed some concepts of
modularization for GAP. This is the result of the discussion which I will
also put in a file `dev/modules.txt'

Modularization of GAP
======================

There are three levels of ``separateness'', that are roughly contained in
each other:
The first is a purely software engineering level of ``Modules''. A module is
a piece of code which provides certain functionality via a defined set of
interfacing functions. On a conceptual level the library is already split
into modules, probably later this spearation will be made more explicit by
attaching names and version numbers to modules.  Eventually it is intended
to make modules identifiers that are not part of the interface to be
inaccessible from outside the module.
Typical modules would be ``permutation groups'',``pc groups'',``linear
algebra'' &c.


The second level, ``Components''  describes parts that may be installed
(and if they are installed they will be used) but beyond losing the specific
functionality there is no harm in doing so. This is currently already done
with most data libraries, code like Galois group identification or Small or
Transitive group constructions also would be separate components.
Eventually (after 4.1) we intend to separate components in an own directory
subtree `cpt'. There will be a file `cpt/cmpnents.g' that contains
sufficient information for GAP to know about all components and to load them
automatically if the functionality is required. This will be invisible to
the user. The release or installation of components is in principle
completely independent of the main body of GAP. Thus it will be possible to
install further components at a later point (at possibly the only cost of
editing the information file), for example if new or updated data libraries
become available. 
A side effect of this is that the documentation of a component has to be
eventually separated from the main GAP documentation, i.e. its reference
manual (and probably tutorial) will become own book(s).

The third level are (Share)``Packages''. The main distinction to components
is that they are outside contributions which have not been adopted by the
GAP group. To make it clear to a user that she is using such code (both for
the recognition of other peoples work but also to make clear that the GAP
group will not maintain the code) packages must be loaded explicitly. At
this point there then also is the possibility to display a short banner.
Share packages will be refereed and will reside in the `pkg' directory.

To sum up everything:


Name: 	   Modules	  	    Components		    Packages

Idea/	   Software                 Optional loading        Authorship,
Concept:   engineering		       			    Maintenance

Aims,      ``independent''          system will work        Refereeing,
Require-     evolution,              without them,          ``fame and blame'',
ments:     explicit dependencies,   Reasonable cost if      Distinction made
           documented interface      present but not used,   for user.
	   			    potential independent
				     release

Mechanism  Completion files	    special code in init.g,  RequirePackage
for                                 functions produced by
loading:                             `ReadAndCheckFunc'.

Alexander Hulpke, 6-May-98


