Kenny <email@example.com> wrote:
| Rob Warnock wrote:
| > Kenny <firstname.lastname@example.org> wrote:
| > +---------------
| > | I got it! Every form returning a value is necessary for us to have the
| > | functional paradigm /available/ to us, and it is a fine paradigm, we
| > | just do not want to be enslaved to never changing state.
| > +---------------
| > And it is precisely this lack of "enslavement" which motivated
| > CL to *silently ignore* excess return values and provide NIL
| > for excess caller requests for them, whereas the Scheme standards
| > [and most Scheme implementations] blow chunks at any caller/callee
| > mismatch on number of values.
| Omigod!!! Why wasn't I told?? Throw me a bone, people!
| Somewhat more seriously, duh-yamn, I never heard this one before.
| So in Scheme I would die asking floor to give me the floor if I
| did not pretend to be interested in the remainder.
Yup. As pointed out in a parallel reply, in Scheme FLOOR is *just*
FLOOR and MOD is *just* MOD [no REM per se]. However, R6RS introduced
a new standard library procedure [not available in R5RS or earlier],
DIV-AND-MOD, which returns two values, see:
184.108.40.206 Arithmetic operations
But caller/callee values still must exactly match, see:
5.8 Multiple return values
11.15 Control features
The continuations of all non-final expressions within a sequence
of expressions, such as in lambda, begin, let, let*, letrec, letrec*,
let-values, let*-values, case, and cond forms, usually take an
arbitrary number of values.
[That is, the places in "bodies" [implicit PROGNs, in CL] that would
throw away *a* value will also throw away any number of values.]
Except for these and the continuations created by call-with-values,
let-values, and let*-values, continuations implicitly accepting a
single value, such as the continuations of <operator> and <operand>s
of procedure calls or the <test> expressions in conditionals, take
exactly one value. The effect of passing an inappropriate number of
values to such a continuation is undefined.
(call-with-values producer consumer) procedure
Producer must be a procedure and should accept zero arguments.
Consumer must be a procedure and should accept as many values as
producer returns. ...
Implementation responsibilities: After producer returns, the
implementation must check that consumer accepts as many values
as consumer has returned.
So there you have it! [Just one more reason I switched to CL, b.t.w.]
To be fair(?), the one obvious escape-hatch *is* supported, in that a
procedure with a single &REST arg [in Scheme, (LAMBDA REST BODY...)]
can be used as a consumer that will will accept any number of values.
And thus one could define a near-equivalent of CL's MULTIPLE-VALUE-LIST
in Scheme this way:
(define (multiple-value-list producer) ; Note: PRODUCER must be a thunk
(call-with-values producer (lambda rest rest)))
or more simply:
(define (multiple-value-list producer)
(call-with-values producer list)) ; Assumes LIST has not been rebound
p.s. Allowing a Scheme MULTIPLE-VALUE-LIST take a function-call
FORM arg [as in CL] instead of a PRODUCER thunk arg would require
MULTIPLE-VALUE-LIST to be a macro.
Rob Warnock <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607