CoCoA » CoCoA-5

JAA is not convinced about using IsDefined to check whether a package has been loaded.
One solution is to search through the packages listed in packages(); note that the package names are strings here!
Andraschko asked whether another name for packages might not be better: e.g. ListOfPackages or PackageList

Being able to test whether a package is present could be useful during development... I wonder whether it should also say at what time the package was loaded (might also be useful info).

A problem with Requires is that CoCoA does not usually know in which directory/ies to search for packages under development. Maybe we should add a "package path" feature? If so, how exactly would that work?

One problem with specifying paths is that two packages with the same name but in different directories can lead to unexpected behaviour if just the first matching file is used. Maybe the whole path should be searched, and an error produced if more than one file matches? Should the path length be limited? Why?

UPDATE Now I see that there is already a CocoaPackagePath, but that contains a single directory (for the "official packages").

Regarding point (B). Andraschko is right that the current documentation is not good (and not well-organized).
After speaking to him, I think that we should make the first step and improve the doc; then ask Andraschko for
feedback on improving it.

I have added the keyword package to another entry; now the list of related manual entries is

 ? CocoaPackagePath
 ? export
 ? packages
 ? Introduction to Packages
 ? First Example of a Package
 ? Package essentials
 ? Sharing Your Package
 ? Commands and Functions for Packages
 ? Supported Packages
 ? Galois Package

Here is a short excerpt from an email in the JSAG editors forum:
Here's the list of advice to authors that we've accumulated over the years, for Macaulay2:
https://github.com/Macaulay2/M2/wiki/Package-Writing-Style-Guide

Macaulay2 has extensive guidelines about writing packages. To be honest, this seems like overkill for CoCoA (at the moment, anyway). However, the idea of better guidelines is surely good.

Regarding point (C) why must a package export at least 1 function?

A work-around would be to create a function with a long and complicated "random" name and export that; but this would pollute the global namespace.

I do not know what Andraschko's specific situation is, but I could imagine a package of "common internal" functions which are used in two other separate packages, but these "common internal" function are not appropriate for public consumption.

We could also allow something like export NOTHING at the start of a package which suppresses the warning; this would also tell the reader of the package code that it is intentional that no functions be exported.

The simplest change is just to remove the code which issues the warning... not sure that that is the best solution.
Comments, suggestions? Perhaps we can discuss on Friday?

NOTE to avoid introducing new keywords we could used export skip as the signal that nothing is to be exported.

John Abbott wrote:

Regarding point (C) why must a package export at least 1 function?
We could also allow something like export NOTHING at the start of a package which suppresses the warning; this would also tell the reader of the package code that it is intentional that no functions be exported.

I like that. Let's look for the best keyword.

Dedicated issue: #1495