[r6rs-discuss] "Unspecified"

From: Felix <pfr6rs>
Date: Fri Oct 6 10:58:34 2006

Mike-

On Oct 6, 2006, at 10:33 AM, Michael Sperber wrote:

>
> Felix <pfr6rs_at_pnkfx.org> writes:
>
>> Or are you implying that R6RS would also be changed so that
>> everywhere
>> we currently see "the value returned by foo is the unspeciifed
>> value"
>> we would instead see something to the effect of "the values returned
>> by foo are indistinguishable from those that would be returned by an
>> invocation of the procedure named unspecified to the same
>> continuation" ?
>
> No. I'm saying that the unspecified procedure returns an unspecified
> number of unspecified values, possibly a different number of different
> values each time around. By analogy, the return value(s) of
> procedures like `vector-set!' would also be specified this way, but as
> no relationship between the return values of different invocations of
> `unspecified' exists, no such relationship between the return values
> of `unspecified' and those of `vector-set!' exists, either.

Okay. I was trying to say that there is no way for an r6rs-compliant
single-value accepting continuation to tell that vector-set! was
invoked rather than unspecified based solely on the return value(s)
of the invocation. Replacing "would be returned" with "could be
returned" gets my sentence closer to what you are saying and closer
to what I intended to say. In any case, I think I understand your
intent now.

> The usefulness of providing `unspecified' in the report is that it
> allows a programmer to say "I don't want to specify the return values
> in this case", where often #t or #f or '() or the unspecific value
> mentioned in R5RS is returned inadvertently, inviting clients to rely
> on those values.

I agree that this is useful. (That's why I said I hoped we would be
removing the predicated named "unspecified?", by the same argument.)

But you haven't addressed why your proposal would placate the people
who are arguing for vector-set! to return zero values. Perhaps I was
misinterpreting the discussion, but I thought some of the motivation
for making it return zero values was for things like (if (begin
(vector-set! x 3)) 4 5) to fail fast, rather than make an unspecified
choice between 4 and 5. Did I make an incorrect inference?

Another alternative for remaining compatible with Will's code would
be to make the continuations for the binder expressions in a let*
(but _not_ a let) accept zero or one values, where binding
continuation would coerce zero values to an (or the) unspecified
value. It makes the macro for let* hairier than usual, but we have
the benefit of allowing the fail-fast behavior in an instance of a
let expression rather than a let* expression. We would obviously
have to generalize other macros such as letrec* in the same manner.
(This is only a benefit if the fail-fast behavior is desirable in the
first place; that is, I am assuming my inference from the preceding
paragraph is correct.)

-Felix
Received on Fri Oct 06 2006 - 10:58:25 UTC