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.

-------