Email list hosting service & mailing list manager

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 Nieper-Wißkirchen 05 May 2020 08:09 UTC

Am Di., 5. Mai 2020 um 08:35 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:

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

PS: Another point is that the boxes of SRFI 195 can be implemented in
a way so that UNBOX and BOX work best with whatever multiple-values
strategy the implementation has chosen. This means that using vectors
is not necessarily the best strategy. It's really another abstraction.

In the case of Chibi, where multiple values are passed as tagged lists
(Gambit seems to use a similar model), a fast implementation would be:

(import chibi)
(import (srfi 9))

(define-record-type <box>
  (make-box v)
  box?
  (v unbox box-set!))

(define (box . v*) (make-box (%values v*)))
(define (set-box! b . v*) (box-set! b (%values v*))

(On the other hand, procedures that retrieve a specific value in a box
should be of relatively minor importance. If these have to be as fast
as possible, vectors instead of boxes are the better abstractions.)