On 2009-07-14, at 19:35 , Robert Goldman wrote:

james anderson wrote:

[...]

4. if one would like to see the code at the version which constitutes  
the current approach to this issue, which revision should one pull?

I don't have a good answer for this, sorry.

I think that James clearly states the issues.  I propose we just try to
come to consensus on something like the following:

1.  We specify which of the system string initargs are actually optional.

then either

2a.  We specify these as being of type string and specify that they take
"" as a default.  Supplying NIL would be a type error.  For the benefit
of non-type-checking lisps, we could add :after methods on
initialize-instance to reject non-string values.

2b.  We specify that the type is (or null string) because we want to be
able to distinguish unsupplied from explicitly empty.


These both seem reasonable alternatives, as long as we state one of them
clearly.

If someone will express a clear preference that isn't shouted down, I'd
be happy to provide help either documenting or coding up support.

i propose, 2b iff some operator depends on the distinction. otherwise 2a.

Here are the initargs from which we have to choose:

:licence :license :maintainer :author :long-description :description
:default-component-class :if-component-dep-fails :components :properties
:pathname :parent :do-first :in-order-to :name :version

Of these, I believe our discussion pertains primarily to

:license/:licence
:maintainer
:author
:description and :long-description
:version

Are these all truly optional?  Personally, I wish that :version wasn't,
and/or that we enforced some standard on values supplied there, since
it's easy to put in something that will cause version-satisfies to choke.

How about we confine our attention to all of these EXCEPT :version,
which is worthy of a discussion of its own.

These are all going to be used primarily by software which simply
displays information about the systems, and all of that software (unless
there's a 'describe' method) is going to be external to ASDF proper,
which means it's hard for me to answer James' "some operator depends on
the distinction" question.


none of author, description, long-description or maintainer are referenced in the asdf code (nb i'm still with 1.130)
i worry about the potential use-case, that some app would want to impute values from a module to its components.
this argues that NIL should be the default.

i don't know of the uses to which one puts license, but were it to matter, one could argue, that asdf should enforce canonicalized license keywords. i've no idea where to find such a thing, but there must be one "out there". this might require the addition of a "license-description" field (with a "" default).

version, on the other hand, is used internally. i have never used it. the predicate reads as if it requires a string to compare and interprets an unbound slot as a wildcard. that is not good. a distinguished value would be better. it reads as though improvements to the logic to supported internal wildcards and/or interval expressions in the version specification would not hurt its utility.

as to the others:
default-component-class : is cl-source-file
if-component-dep-fails : is :fail
components : are there any arguments against an empty module? if not this should default to NIL.
properties : is NIL.
pathname : the version i have reads as if this value is defaulted by the interface operator. if that is the intent, the class definition should  have an error form for the initform.
parent : is NIL
do-first : id NIL
in-order-to : is NIL