Am Di., 5. Mai 2020 um 02:29 Uhr schrieb Marc Feeley <xxxxxx@iro.umontreal.ca>:

> 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).

As the objects specified in SRFI 195 encompass the boxes of SRFI 111,
it wouldn't have made sense to choose a new name. In this regard, it's
fortunate that SRFI 111 didn't choose the name "cell".

> 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! ?

In some sense, already the SRFI 111 boxes are redundant because a
vector or list of length 1 can already store a single value (moreover,
lists of length 1 are probably at least as efficient as the
box-records of SRFI 111 in most Schemes). What SRFI 111 mainly does is
to establish a new type (that of a box), which can be tested with
BOX?. This way, I can make procedures box-aware:

(define (sum a b)
  (+ (maybe-unbox a) (maybe-unbox b)))

(define (maybe-unbox x) (if (box? x) (unbox x) x))

By extension, the same holds for SRFI 195. Of course, an
implementation is free to use vectors to represent boxes as long as
these vectors are specially tagged to that they can be distinguished
from ordinary vectors by BOX?.

> 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.

Please see my reply to John's and Shiro's request where I propose a
general interface, which is not restricted to the case of boxes.