[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Multiple values for R4RS.



   Date: Tue, 22 Aug 89 14:19:50 pdt
   From: Guillermo J. Rozas <jinx@hpesogg.hp.com>

       This is an extreme position.  The proposed functionality is
       useful even in the absence of ACCEPTS?  

   It's much less extreme than imposing a particular fascist semantics on
   those who don't find it interesting or useful.

I agree, with Norman, that the proposed functionality is useful in the
absence of `accepts?'.  However, tossing around words like "extreme"
and "fascist" in this fashion seems hypocritical.  Aside from the
differing emotional charges attached to these phrases, both seem to
have the same purpose: discrediting the opposition by distancing them
from the hypothetical "middle ground" (or "moral majority" if you
prefer the three-red-stars-extra-spicy emotional charge).  Let's try
not to make arguments that presume knowledge of the consensus.

As an aside, I have no objection to implementing `accepts?'; I think
that it is very useful, whether or not you have multiple values.  But
I dislike that particular name because it is too vague; I'd prefer
something more like `procedure-accepts?' or (as in MIT Scheme)
`procedure-arity-valid?'.

       [2] Do you think VALUES and APPLY-VALUES as defined reflect existing
       practice?  For example, in T, VALUES = RETURN, and APPLY-VALUES = 
       (LAMBDA (X Y) (RECEIVE-VALUES Y X)), and MIT Scheme has the
       functionality. 

   MIT Scheme does not quite have it.  It is not integrated with
   continuations at all (I don't know if T's is either).  I think that it
   is not worth putting in, if I cannot accomodate users who would like
   Common Lisp style truncation of values, or who want to be able to port
   Common Lisp code a little more easily.  I find the backwards
   compatibility that "truncation" offers to be the most significant
   feature in multiple values, and would use CPS otherwise.

I disagree with this statement -- multiple values have usefulness
independent of the "truncation" feature, and I feel they are worth
having anyway.  Despite the fact that MIT Scheme's multiple values are
not fully implemented, I have found them quite useful and I have
written much code that uses them.

CL's handling of "extra" values is distasteful to me, because it makes
the standard behavior complicated; I think that values should be
discarded only when that is explicitly stated by the code.  This is
not to say that I would be extremely upset should such a semantics be
adopted, because I would just avoid using "truncation".  But on
aesthetic grounds I would prefer something simpler.