I guess such a simple traversal algorithm can give you a collection of modules, if you have already annotated those modules which belong to a package and those modules which do not yet belong to a package. It will yield a subset of the modules that do not yet belong to a package.
But I have the feeling that this misses the point. I think software engineering for packages has a different goal than simply delivering one package. Usually one is faced with multiple packages and these packages can have dependencies which are rooted in the dependency of the modules itself.
Mathematically:
M: The set of modules
P: The set of packages
p(m): The package a module belongs to or null.
So if I have module dependencies, I can derive package dependencies from it:
d(m1,m2): The module m1 depends on the module m2
d'(p1,p2): The package p1 depends on the package p2
d'(p1,p2) <=> exists m1,m2 (p(m1)=p1 & p(m2)=p2 & d(m1,m2))
Your algorithm might derive one package p which then might depend on some packages p1, .., pm which have been already used to annotate the existing modules. But software engineering has found many ways to identify multiple packages, typical architectures are vertical layering, horizontal layering, etc.. Maybe there are also algorithms for that.
But matters are not that simple. Packages are usually defined to help in the co-evolution of modules and to facilitate change management and release management. If modules co-evolve one does not want to release one module after the other. One wants to release a set of modules that has reached the same evolution level, so that this set of modules can fruitfully interact.
But if we have evolution of modules we will also
have evolution of packages. And this evolution will
happen if you have a single packages or if you go
more with the multiple packages for your stuff. And I
am not sure whether the existing package systems for
Prologs already help here. What I see for SWI-Prolog
is for example a versioning of packages and a todo
list for packages:
http://www.swi-prolog.org/howto/PackTodo.txt
The above todos make all sense. But they do not directly address package dependency and their evolution. In Jekejeke Prolog I am currently experimenting in improving the module dependency. The idea is for example that the end-user can load a module clpfd via the following command:
?- use_module(library(clpfd)).
If a package is installed and activated that has a module clpfd the command will succeed. And if no such package is installed or a package is installed and not yet activated the command will fail. The home package respectively the module clpfd will use other modules and thus packages. If it uses a module local to its own package it can do so as follows, no need for the library/1:
?- use_module(helper).
But if it uses a module that is not local to its own package it typically does differently. For example a module clpfd might use a module apply. And it will do so with library/1:
?- use_module(library(apply)).
And now we recognize that we will not know by inspecting the clpfd or helper module, when it does the above from where it will take the apply module. We only know the package dependency when we have a particular set of packages at hand and when we resolve the module name apply to its package.
This flexibility has its pro and cons. The cons are that we cannot establish fixed package dependencies. And that tools for versioning etc.. that rely on fixed package dependencies will not work. So a solution would be to bootstrap versioning for packages from versioning for modules, similar as how we derive dependencies between packages from dependencies of modules.
But I am not yet sure how this would work. The complexity can surely be reduced if we can distinguish between public and private modules. For example the above module helper could be used solely by clpfd, and can be left out when determining package dependencies and package versioning.
My ideas so far:
- Derive package dependencies from modules
- Derive package versioning from modules
- Allow private and public modules inside packages.
Bye