> On May 4, 2020, at 5:59 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
> That seems to me to make the situation of returning multiple values and returning a box as a single value indiscernible.  That can't be the Right Thing.

The “right thing” depends on what the goal is, and I guess that’s the part I don’t fully grasp yet.

Over the years I’ve gotten used to the idea that a box is a cell that contains a single value and in fact the terms box and cell are somewhat synonymous (indeed the term “cell” is even used in MIT Scheme and Scheme48 as part of the names of the procedures operating on single value containers).

SRFI 195 proposes to store multiple values in a box/cell, something that doesn’t sound right to me.  There is already the vector type (and list type) for containing multiple values.  I would find it more natural to extend vectors to suit the goals of this SRFI.  In fact it seems that the main thing that is needed is a way to “unbox” a vector into multiple values (in the |values| sense), which could be called (vector->values v).  So this would give:

   SRFI 195             with vectors

  (box A ...)          (vector A ...)
  (box? obj)           (vector? obj)
  (unbox x)            (vector->values x)           note: (define (vector->values x) (apply values (vector->list x)))
  (set-box! x A ...)   (vector-replace! x A ...)    note: what is the use-case for multiple value set-box! ?

This would require adding the vector->values and vector-replace! procedures, but they seem to be more generally useful anyway.  The vector-replace! procedure could also be eliminated by extending vector-set! to take a variable number of values to set starting at a certain index, i.e. (vector-set! x 0 A ...) = (vector-replace! x A ...) ~= (set-box! x A ...), which is also generally useful.  I’m not suggesting this be done… I’m just pointing out the alternative.  A vector-splice! procedure similar to JavaScript’s splice method is another useful extension to vectors that is even more general for setting multiple values.

My main point is that the box type is interesting specifically because it conveys the idea of a single value.  With SRFI 195 boxes become so similar to vectors that the redundancy stands out, and even more so when other procedures are (possibly) added to SRFI 195 to get the length and extract/modify specific values.

Marc