[cdr-discuss] A proposed convention for *FEATURES*

[Nick Levine]

Some comments on this proposal:

1. Ought this proposal to be a CDR?

At present

    #+(not cdr-42) 

...doesn't necessarily tell us anything - it could just mean that your
proposal hasn't been adopted.

But suppose this proposal is CDR number 5 (as of 2007-08-24 this is
the next in the sequence) and so requires the feature keyword
:cdr-5. Then

    #+(and cdr-5
           (not cdr-42))

...implies that your proposal is in effect and therefore that the
absense of :cdr-42 on *features* means that this implementation isn't
conforming to CDR-42.


2. Names beginning with "CDR-" 

You suggest:

    programmers are discouraged from adding keyword symbols to
    *FEATURES* whose names begin with "CDR-" except as part of
    implementations of interfaces described in CDR documents.

Given that you only specify use of keywords beginning with CDR-<nn>,
I'm curious to know why you restricted keyword use to anything
beginning with CDR-. Grasping at straws, I wonder whether the
implementors of a lisp which employed cdr-consing would want to
announce this to their users by means of the :CDR-CONS feature (the
presence of which would conflict with your suggestion).


3. Read-time conditionals only?

You haven't proposed a means of determining after read-time (for
example: during load of a pre-compiled system, or at runtime) which
CDRs are in effect. I think this weakens your proposal.

On the other hand, the solution (defun featurep) is fairly clear and
has previously been documented "elsewhere":

  http://clrfi.alu.org/clrfi/clrfi-1-featurep

Should this be revisited and proposed as a CDR?


4. Minor typo

I don't know about your reader,, but mine really enjoys complaining
about "too many commas". (See under "Esthetics")


- nick