asdf documentation/*central-registry* bugreport

Greetings,

This applies to the current CVS HEAD version.

The documentation does not seem to match the implementation in the
case of *CENTRAL-REGISTRY*.  README says: "A ssytem directory
designator is either a function designator for a function of one
argument" but SYSTEM-DEFINITION-PATHNAME does (if (and (symbolp
dir) (fboundp dir)) (funcall dir name) (eval dir)) which, as far as
I can see, does not work for function objects (which are function
designators).  Also, according to the documentation a function
always has to return a path as if the system file should always be
found "from" that *CENTRAL-REGISTRY* component.  The implementation
seems to consider NIL as "I didn't find the system file".

The documentation is also ambiguous.  It continues: ", which when
called with the system name will return a directory to look for
.asd files in, or it is a form which will be evaluated".  If I put
a symbol to *CENTRAL-REGISTRY* which is both FBOUNDP and BOUNDP,
the documentation leaves it unclear whether it is evaluated as a
form or called as a function.  As it stands, the implementation
calls it as a function.

FWIW, I think that the usage of functions in *CENTRAL-REGISTRY*
is somewhat suboptimal.  The current method of returning a
directory needlessly restricts the system files to the ".asd"
extension.  Also, I think it would be good to allow functions to
say that "the latest version is now in the core".  I would probably
specify that functions must return one of: NIL for "I didn't find
the system file, move on to the next *CENTRAL-REGISTRY* item", T
for "the latest version is now in the core" or a pathname
designator (or maybe just pathname/pathname namestring) for the
system file.

I would also like to suggest the mode of README to be set to
outline for easier reading.

-- 
Hannu




-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com