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.