Dylan Change Proposal Format

Proposals for changes to the Dylan Reference Manual or the Standard Libraries should be submitted to the dylan-partners@camellia.org mailing list. You can view a sample proposal. Each proposal should either be in plain ASCII format, limited to 72 columns (so that the text fits without horizontal scrolling in popular web browsers), or in HTML format. Include text for the following seven fields (feel free to copy and paste from here). The fields are defined below.

PROPOSAL NAME: 

PROBLEM DESCRIPTION:

PROPOSAL: 

RATIONALE: 

EXAMPLES: 

COST TO IMPLEMENTORS:

RELATED PROPOSALS: 

REVISION HISTORY:

PROPOSAL NAME:

A one-line descriptive title, e.g. "Make the \^ operator right-associative."

PROBLEM DESCRIPTION:

A description of the problem to be solved. This is distinct from and should not be confused with the proposal section, which describes an approach to solving the problem described here.

PROPOSAL:

Wording of proposed change/addition. This should be in the format and style of the DRM library document. Whenever possible, supply page or section number, and exact wording of changes, deletions, or additions, and specify if this is a typo fix, clarification, compatible addition, or incompatible change.

RATIONALE:

Arguments for and against the proposal. Will the proposal make things easier to use? Faster? Safer? What about for programs that do not use the feature? If its an incompatible change, what problems will that cause? Include a description of the current situation/problem. Include alternatives that were considered, and explain why the current situation is not good enough.

EXAMPLES:

Example Dylan code using the proposal. If relevant, show what code would be like without the proposal, and why that would be slower, harder to code, less safe, etc.

COST TO IMPLEMENTORS:

How hard is it to implement this change? While the RATIONALE section describes the benefits, this section describes the costs. Mention any performance problems. Consider costs to tool implementors: will this make it harder/easier to write a browser, editor, etc. It will help the cause of your proposal if you can show an implementation: a definition for a function or macro you propose; or if it is a language syntax extension, show a grammar. In either case, verify that it works by running your function/macro/grammar in an existing implementation whenever possible.

RELATED PROPOSAL:

Names of PROPOSALs that bear on this one.

REVISION HISTORY:

Dates and authors of original proposal and any revisions.

STATUS:

One of: open until dd-mon-yy, withdrawn, rejected, accepted. Don't include this field in your proposal; it will be added by the moderator.