[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 <firstname.lastname@example.org>
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)
 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
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.