[MIT-Scheme-devel] R7RS and values.

[Matt Birkholz]

Did I hear that VALUES might not be terribly expensive nor difficult
to implement?  Taylor suggested a simple trap is all we need(?).
I have tried to work out the details here.

As I understand it, POP-RETURN would "just" trap on a new type code in
the value register.  VALUES would cons vectors of this type (unless
there is just one value).  If a callee returns such a vector, the trap
raises an arity mismatch condition (unless the continuation is
whacky).  Whacky continuations would NOT trap because they will be
using APPLY.  Thus:

(define (values . args)
  (if (= 1 (length args))
      (car args)
      (system-list->vector (ucode-type multiple-values) args)))

(define (call-with-values producer consumer)
  (declare (ignore-multiple-values-traps val))
  (let ((val (producer)))
    (if (object-type? (ucode-type multiple-values) val)
        (apply consumer (system-vector->list val))
        (consumer val))))

Normal continuations suffer only a type code test.  Continuations
internal to a sequence would pay nothing at all.  They can continue to
ignore the value register and not worry about the stack.

The only change to the compiler is the conditional inclusion of the
multiple-values-trap in POP-RETURN (with new compiler utility to raise
the mismatch condition).  The interpreter would get a corresponding
test in pop_return.  The runtime: a new error type.  Anything else?

Of course code like this:

(define (bounding-box vertices)

  (define (x&y vertex)
    (values (car vertex) (cdr vertex)))

  (guarantee-pair vertices 'bounding-box)
  (call-with-values (lambda (x&y (car vertices)))
    (lambda (init-x init-y)
      (let loop ((vertices (cdr vertices))
                 (min-x init-x) (min-y init-y)
                 (max-x init-x) (max-y init-y))
        (if (pair? vertices)
            ;; Much consing and applying.
            (call-with-values (lambda () (x&y (car vertices)))
              (lambda (x y)
                (loop (cdr vertices)
                      (min min-x x) (min min-y y)
                      (max max-x x) (max max-y y))))
            (values min-x min-y max-x max-y))))))

might be disappointingly slow even when x&y is integrable.

This implementation might actually be more performant than what we
have now for the single reason that values would cons a vector, not
a closure (thus not flush all the caches, thanks Harvard!).

I've almost talked myself into it.

Anyone else?

What did I miss?