Re: THE VALUES

[NGALL@G.BBN.COM]

    Date: Wed, 23 Jul 86 12:54 EDT
    From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
    To: Rob MacLachlan <RAM@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
    Subject: THE VALUES
    In-Reply-To: <RAM.12224974495.BABYL@C.CS.CMU.EDU>
    Message-ID: <860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
    
	Date: Wed, 23 Jul 1986  09:50 EDT
	From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
    
    
	    Well, I think everyone is wrong about this one. (THE (VALUES ...) ...)
	specifies the functional type of the continuation.  This is in effect
	what CLTL already says: "...indicates the parameter list of a function
	that, when given to multiple-value-call along with the values, would
	be suitable for receiving those values."
    
	    I strongly disagree with any proposal which gives THE mandatory
	run-time semantics.  THE is a declaration --- its presence should not
	change the meaning of a correct program.  If the form returns too many
	values, then the program is in error and the result is undefined.
    
Agreed.

	    I agree that it is highly desirable to be able to specify the
	type of the first value without worrying about the actual number of
	values.  To this end, I propose that (THE FOO ...) should be
	synonomous with the (THE (VALUES FOO &REST T) ...).  This allows one
	to say things like (THE FIXNUM (TRUNCATE ...)).
    
Agreed.

    OK, I can buy that.  I still want a form for run-time semantics for the
    purposes of multiple-value-call and multiple-value-list.  Something like
	    (take-values <something>
			 <form>)
    where <something> is not evaluated and can be either a non-negative integer
    which is the number of values, or a list of type specifiers.  (An
    integer is shorthand for (t t ...).)  The take-values form returns
    exactly the number of specified values, by truncating or padding the
    values returned by <form> as necessary.  This can be naively implemented
    as a macro given what is currently in CLtL, but I think it is useful
    enough for some compilers to take advantage of it that it should be
    considered part of the language.
    
Hmmm... I'll think about this one.  I dont like the name or the
integer stuff, but I think there is a need for such a form.

	    It should also be clarified that the VALUES type specifier may
	have &ALLOW-OTHER-KEYS.

Agreed.

-- Nick