[LISPWORKS][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue DEFINE-METHOD-COMBINATION-BEHAVIOR Writeup

Issue:        DEFINE-METHOD-COMBINATION-BEHAVIOR

Forum: X3J13 Letter Ballot

References: DEFINE-METHOD-COMBINATION (X3J13/92-102, p7-77)

Public review comment Barrett-23

Public review comment Loosemore-9

Category: CLARIFICATION

Edit history: 21-Jun-93, Version 1 by Steele (based on text by Loosemore)

Status: Proposal CLARIFY passed 11-0 on letter ballot 93-304.

Problem Description:

A portion of a previously approved technical issue

(CLOS-MACRO-COMPILATION) that specified when method combinations are

executed was not incorporated into the draft.

Proposal (DEFINE-METHOD-COMBINATION:CLARIFY):

Add this statement to the description of DEFINE-METHOD-COMBINATION:

If a \macref{define-method-combination} \term{form} appears as a

\term{top level form}, the \term{compiler} must make the

\term{method combination} \term{name} be recognized as a valid

\term{method combination} \term{name} in subsequent \macref{defgeneric}

\term{forms}. However, the \term{method combination} is executed

no earlier than when the \macref{define-method-combination} \term{form}

is executed, and possibly as late as the time that \term{generic functions}

that use the \term{method combination} are executed.

Test Case:

Not provided.

Rationale:

Incorporate technical change already approved.

Current Practice:

Not provided.

Cost to Implementors:

Probably relatively small.

Cost to Users:

None. This change doesn't affect anything already guaranteed to the user.

Cost of Non-Adoption:

Vagueness in the language specification.

Benefits:

Better program portability.

Editorial Impact:

Small. A few small, localized edits.

Aesthetics:

Mostly neutral.

Discussion:

This addresses comment Barrett #23 and Loosemore #9.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996-2005, LispWorks Ltd. All rights reserved.