Email list hosting service & mailing list manager

Generalized arrays in the presence of call/cc Bradley Lucier (27 Jul 2022 12:39 UTC)
Re: Generalized arrays in the presence of call/cc Marc Nieper-Wißkirchen (27 Jul 2022 13:15 UTC)
Re: Generalized arrays in the presence of call/cc Bradley Lucier (27 Jul 2022 15:11 UTC)
Re: Generalized arrays in the presence of call/cc John Cowan (27 Jul 2022 20:19 UTC)
Re: Generalized arrays in the presence of call/cc Marc Nieper-Wißkirchen (27 Jul 2022 21:04 UTC)
Re: Generalized arrays in the presence of call/cc Bradley Lucier (28 Jul 2022 21:47 UTC)
Re: Generalized arrays in the presence of call/cc John Cowan (30 Jul 2022 15:33 UTC)
Re: Generalized arrays in the presence of call/cc Marc Nieper-Wißkirchen (30 Jul 2022 17:06 UTC)
Re: Generalized arrays in the presence of call/cc Bradley Lucier (30 Jul 2022 19:48 UTC)
Re: Generalized arrays in the presence of call/cc Bradley Lucier (06 Aug 2022 17:58 UTC)
Re: Generalized arrays in the presence of call/cc John Cowan (06 Aug 2022 18:05 UTC)
Re: Generalized arrays in the presence of call/cc Bradley Lucier (10 Aug 2022 18:27 UTC)

Re: Generalized arrays in the presence of call/cc Bradley Lucier 27 Jul 2022 15:11 UTC

On 7/27/22 9:15 AM, Marc Nieper-Wißkirchen wrote:
> The specification of `map` and `vector-map` in the R7RS is archetypical
> for such well-behavedness of higher-order procedures.

Thanks for the pointer.  For vector-map it says:

If multiple returns occur from vector-map, the values returned by
earlier returns are not mutated.

I think the following implementation satisfies this condition, but I
don't think it's what people had in mind:

(define (screwy-vector-map f v)
   (let* ((n (vector-length v))
          (temp (make-vector n)))
     (do ((i 0 (fx+ i 1)))
         ((fx= i n) (vector-copy temp))
       (vector-set! temp i (f (vector-ref v i))))))

It appears that if f in (screwy-vector-map f v) captures continuations
for different values of i, say k0 with i=3 and k1 with i=5, and then f
returns different values depending on which continuation it's following,
then what k0 and k1 return may depend on whether k0 is called before k1
or vice versa.

But once a value is returned by the original call to screwy-vector-map
or by k0 or k1, it is never changed by calls to k0 or k1 (because of the
call to vector-copy).

(I spent about 20 minutes working on a specific example but thought it
would be simpler just to post this email, because screwy-vector-map is
just supposed to be illustrative.)

So I'm beginning to be suspicious of any code that has *-set! in it.
But it appears to me that the loops beginning at the lines

https://github.com/scheme-requests-for-implementation/srfi-231/blob/f8bdf64e755216cba4722925a3b234f67b3e3e09/generic-arrays.scm#L787

and

https://github.com/scheme-requests-for-implementation/srfi-231/blob/f8bdf64e755216cba4722925a3b234f67b3e3e09/generic-arrays.scm#L888

are call/cc save, even though I use set! to compute the arguments to the
procedure f.

Do people disagree with this assessment?

Brad