CLHS: Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES Writeup

#

## Issue MULTIPLE-VALUES-LIMIT-ON-VARIABLES Writeup

    Issue:             MULTIPLE-VALUES-LIMIT-ON-VARIABLES
    References:        MULTIPLE-VALUES-LIMIT,
                       MULTIPLE-VALUE-SETQ, MULTIPLE-VALUE-BIND,
                       NTH-VALUE
    Related issues:    none
    Category:          CLARIFICATION
    Edit history:      v1, 13 Feb 1991, Sandra Loosemore

    Problem description:

      The constant MULTIPLE-VALUES-LIMIT is defined in CLtL as the upper
      exclusive bound on the number of values that may be returned from
      a function.  Does this limit also apply to the number of variables
      that may be bound or assigned by MULTIPLE-VALUE-BIND or
      MULTIPLE-VALUE-SETQ?  Or are the excess variables simply given values
      of NIL?

      There are two proposals, UNDEFINED and NIL.

    Proposal (MULTIPLE-VALUES-LIMIT-ON-VARIABLES:UNDEFINED):

      Clarify that MULTIPLE-VALUES-LIMIT applies to the number of variables
      that may be bound or assigned by MULTIPLE-VALUE-BIND or
      MULTIPLE-VALUE-SETQ and the index argument to NTH-VALUE, as well
      as to the number values that can actually be returned.

      Rationale:

        It's conceivable that these forms for accessing multiple values
        could be implemented in such a way that they break if you try to
        access values beyond MULTIPLE-VALUES-LIMIT.

    Proposal (MULTIPLE-VALUES-LIMIT-ON-VARIABLES:NIL):

      Clarify that MULTIPLE-VALUES-LIMIT applies only to the number of values
      that can actually be returned, and not to the number of variables that
      may be bound or assigned by MULTIPLE-VALUE-BIND or MULTIPLE-VALUE-SETQ
      or the index argument to NTH-VALUE.  As usual, NIL if there are not
      enough values actually returned.

      Rationale:

        There are ways of implementing these forms for accessing multiple
        values in such a way that they don't break if you try to access
        values beyond MULTIPLE-VALUES-LIMIT.

    Current Practice:

      I don't know.

    Cost to Implementors:

      For proposal UNDEFINED, none.
      For proposal NIL, more care needs to be taken in implementing multiple
      values.

    Cost to Users:

      For proposal NIL, none.
      For proposal UNDEFINED, loss of portability for some programs (probably
        very rare).

    Cost of non-adoption:

      Confusion about what implementation techniques for multiple values are
      valid.

    Performance impact:

      Hard to say.

    Benefits:

      The cost of non-adoption is avoided.

    Esthetics:

      Proposal NIL is probably better from a purely theoretical point of view,
      since it doesn't complicate the language by imposing arbitrary limits
      on programs.

    Discussion:

      Loosemore prefers proposal NIL, as long as it doesn't cause problems
      for implementors.
    -------

Copyright 1996-2005, LispWorks Ltd. All rights reserved.