Proposal Format (Version 13)

[Masinter.pa@Xerox.COM]

This is the proposal format with some changes to section titles, a bit
of reorganization (to put the Costs together and the Benefits together),
and some minor changes to the rules: I described what I thought was an
Example vs a Test Case, etc.

!
  Format for proposals to the cleanup committee (Version 13)
                    November 20, 1987


Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upper-case all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.

Issue:         >>A short descriptive label, which starts with a name
               which occurs in the index of CLtL, and be a suitable
               symbol in the Common Lisp style, e.g., CDR-TERMINATION.<<

References:    >>The pages of CLtL which describe the feature being
               discussed, and other references, including other
               related issues.<<

Category:      >>One or more of:
               CLARIFICATION -- proposal to resolve an ambiguity or case
               of under-specified situation in CLtL, where this
               ambiguity interferes with portability of code.
               CHANGE -- proposal for an incompatible change.
               ADDITION -- proposal for a compatible extension<<

Edit history:  >>Author and date of submission (version 1), and author
               and date of subsequent versions.<<

Problem description:

>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<

Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing.  Ideally, this should take the form of
text that could be dropped into the new specification document.
Proposals should be for changes to Common Lisp, rather than changes to
CLtL.  If necessary, propose a set of labelled alternatives here, rather
than a single proposal. Each proposal must be a complete design; do not
leave out details.  Avoid arguing for the proposal here, just describe
it.<<

Test Cases/Examples:

>> Examples are samples of Common Lisp code that illustrates the issue.
along with explanatory text.

Test Cases are simple stand-alone expressions which are valid and
do not signal an error if the proposal is adhered to. (Use ASSERT
if you need.)

<<

Rationale:

>> A one or two sentence summary of the arguments that follow. <<

Current practice:

>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more.<<

Cost to Implementors:

>>What is the cost to implementors of adopting the proposal?  How much
implementation effort is required?  Is public-domain code available? For
pervasive changes, can the conversion be automated?<<

Cost to Users:

>>For incompatible changes, what is the cost to users of converting
existing user code?  To what extent can the process be automated? How?<<

Cost of non-adoption:

>>How serious is it if nothing is done? <<

Benefits:

>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<

Esthetics:

>>How does this proposal affect the simplicity of the language, ease of
learning, etc. You can spell it aesthetics if you like. <<

Discussion:

>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. A blow-by-blow account of debates is not necessary. <<