Re: Multiple values for R4RS

[R. Kent Dybvig <dyb@iuvax.cs.indiana.edu>]

> Date: Fri, 25 Aug 89 21:18:22 PDT
> From: will@cs.uoregon.edu
> Subject: Multiple values for R4RS
> 
> The reason I don't like a semantics in which (VALUES E) is not required
> to be the same as E doesn't have anything to do with whether I can
> implement the semantics I like (I can, regardless).  It has a little bit
> to do with whether I can write certain portable programs (see example
> below), but not much.  It mainly has to do with the complexity of Scheme
> considered as a programming language independent of its implementations.
> 
> The only way that I can see to understand or explain a semantics in
> which (VALUES E) is not required to be the same as E is to postulate
> an entirely new kind of object whose sole purpose is to communicate
> between VALUES and receivers of multiple values.  I then have to say
> that the effect is undefined (or an error) if this new kind of object
> ever gets passed to an ordinary continuation, procedure, or special
> form (e.g. IF).  That's a considerable amount of intellectual overhead
> if the only reason for it is to allow some particular implementation
> "to signal an error whenever someone attempts to return (VALUES ...)
> to a context where multiple values aren't expected, or something other
> than (VALUES ...) to a context expecting multiple values".

I don't see it.  If you want to build "values" and "with-values" into
the semantics, where "(values e)" is distinct from "e", you will have
to use a tagged sequence instead of a sequence, add a few lines total
for "values" and "with-values", make a slight modification to "send",
and make another slight modification to "single".  Am I missing
something?

> Here's an example of a potentially useful procedure that would be
> less useful if (VALUES E) is not required to be the same as E:
> 
>     ; Given two procedures F and G, COMPOSE returns a procedure that
>     ; acts as the composition of F and G.  The arguments to F consist
>     ; of all the values returned by G.

This is a good example, one I hadn't considered.

> I have given two reasons in this message, both of which are independent
> of the truncation feature.  I'm curious to know what you think of them,
> and even more curious to know why signalling that error is so important
> to you.

My reasoning is based on the assumptions that (a) it is likely that a
program that doesn't work if "(values e)" is distinct from "e" was
probably written that way by mistake, and (b) any program written with
the assumption that "(values e)" was equivalent to "e" could be easily
rewritten to one that does not assume that "(values e)" is equivalent
to "e".  Clearly, assumption (b) was incorrect.

I now see that there is some value in requiring "(values e)" to be the
same as "e", even in the absense of the infamous "truncation" feature.
There is also some value in requiring (or allowing) "(values e)" to be
distinct from "e".  I see the latter as simpler, not more eomplex, both
in terms of the semantics and in terms of the implementation.  However,
as I said at Snowbird, I am willing to defer to the judgement of the
majority on this issue.

Kent