comments Marc Feeley (04 May 2020 21:21 UTC)
Re: comments John Cowan (04 May 2020 21:24 UTC)
Re: comments Marc Feeley (04 May 2020 21:33 UTC)
Re: comments John Cowan (04 May 2020 21:59 UTC)
Re: comments Marc Feeley (05 May 2020 00:29 UTC)
Re: comments Marc Nieper-Wißkirchen (05 May 2020 06:35 UTC)
Re: comments Marc Nieper-Wißkirchen (05 May 2020 08:09 UTC)
Re: comments Marc Nieper-Wißkirchen (05 May 2020 06:21 UTC)
Re: comments Marc Nieper-Wißkirchen (17 Aug 2020 14:47 UTC)
Re: comments Marc Nieper-Wißkirchen (17 Aug 2020 14:48 UTC)

Re: comments Marc Feeley 04 May 2020 21:33 UTC

> On May 4, 2020, at 5:23 PM, John Cowan <xxxxxx@ccil.org> wrote:
>
> A values object looks to me like an immutable box: see SRFI 111 for why these aren't very useful.  I agree about the number of values in a box being fixed, though.

As I said allowed but not required.  Gambit’s multiple values objects are mutable and you have these procedures to operate on them:

    (##values X ...)        same as (values X ...)
    (##values-length vals)
    (##values-ref vals i)
    (##values-set! vals i x)
    (##values->list vals)
    (##list->values lst)
    (##values? obj)

A values object can’t be of length 1.  Gambit uses that case to represent the SRFI 111 box object.  This means the same type tag can be used to represent values objects and SRFI 111 box objects, distinguished by their length.  To implement SRFI 195 boxes it would make sense to use this type tag for SRFI 195 boxes of any size, but this would mean that (box X Y) is the same as (values X Y).

Marc