Re: [MIT-Scheme-devel] R7RS and values.

[Taylor R Campbell]

   Date: Thu, 3 Nov 2016 13:15:54 -0700
   From: Matt Birkholz <address@hidden>
   
   > From: Taylor R Campbell <address@hidden>
   > Date: Thu, 3 Nov 2016 18:36:24 +0000
   > 
   > [...]  Did anything other than paths involving CALL-WITH-VALUES and
   > VALUES change?
   
   Nope.
   
Might be worthwhile to try the profiler, and compare the profiles
before/after.

   > It has long been a bug and it's why I introduced BEGIN0, so that we
   > could prepare code to do the right thing before making the right thing
   > the only thing that works.
   
   I was pleased to find only a couple spots needing patching to "pass
   along multiple values".  The team did good.  The lusers may still get
   sore, but our canon offered a good example.

How do you know you got them all?
   
   > I would strongly advise that you make multi-value returns to
   > single-value continuations report an error.  Otherwise, you are
   > quietly changing the semantics of who knows how many continuations.
   
   R7RS says "The continuations of all non-final expressions within a
   sequence [...], take an arbitrary number of values because they
   discard the values passed to them in any event."  It is going to take
   some trouble to clue the VALUES primitive in as to whether it is a
   non-final expression.
   
That excerpt is about (begin (values 1 2 3) ...).  The continuation
inside the BEGIN for the ... is not intrinsically a single-value
continuation; it's more like an ignored-value continuation.

   R7RS also says "The effect of passing no value or more than one value
   to continuations that were not created in one of these ways is
   unspecified."  So I wonder from where the semantics you mention came.

That excerpt is about (list (values 1 2 3)), which I strongly advise
that we report noisily.

If we don't report it noisily, then for code like

(let ((x (f)))
  ...
  x),

your change would cause the semantics of the code to silently change
from passing on all values to passing on only the first value.  Right
now in your branch, it seems that (list (values 1 2 3)) gives the list
(1) rather than an error.

Of course, this code should really do

(begin0 (f)
  ...)

but I'm sure there remain many cases where that intent has not been
expressed.  E.g., see MAKE-CALL-WITH-FILE in runtime/fileio.scm -- it
should use BEGIN0 but it doesn't, even in your branch.  So that's at
least one case you haven't caught.