[r6rs-discuss] [Formal] proc in hash-table-update! should not mutate hash-table

From: Daniel Villeneuve <daniel_villeneuve>
Date: Fri Feb 23 20:05:04 2007

Jed Davis wrote:
> On Tue, Feb 20, 2007 at 08:16:13PM -0500, Daniel Villeneuve wrote:
> []
> > PROPOSAL
> >
> > Add "<proc> must not mutate the hash-table" as in the
> > specification of map.
>
> I hope that this would be a requirement on the program
> rather than the implementation.

For some systems (e.g., an interactive application that
evaluates users' code on-the-fly), the implementation ends
with the requirement. And that's not that costly to
implement: a counter (to temporarily lock the hash-table)
and an exception handler (to decrement it even when
exceptions are raised).

> And then there are the continuation issues. []

Yes, and these continuation issues should be clarified for
all uses of callbacks in the Standard (map, for-each,
list-sort, vector-sort, vector-map, ...).

For example, here is a test with a continuation captured
while in map:

<call/cc-list>
(define k #f)

(define (f x)
  (call-with-current-continuation
   (lambda (kk)
     (if (and (not k) (negative? x)) (set! k kk))
     (* 2 x))))

(define i 0)
(define v (make-vector 2))

(let ((r (map f '(1 2 3 -4 5 6))))
  (vector-set! v i r))

(set! i 1)
(k -1)

(display v)
(newline)
</call/cc-list>

and here is a similar test using vector-map, with my own
unary version of vector-map:

<call/cc-vec>
(define (vector-map f v)
  (let* ((n (vector-length v))
         (w (make-vector n)))
    (do ((i 0 (+ i 1)))
        ((= i n) w)
      (vector-set! w i (f (vector-ref v i))))))
    
(define k #f)

(define (f x)
  (call-with-current-continuation
   (lambda (kk)
     (if (and (not k) (negative? x)) (set! k kk))
     (* 2 x))))

(define i 0)
(define v (make-vector 2))

(let ((r (vector-map f '#(1 2 3 -4 5 6))))
  (vector-set! v i r))

(set! i 1)
(k -1)

(display v)
(newline)
</call/cc-vec>

Does the Standard clearly states what's the legal output of
these two tests?
--
Daniel
Received on Fri Feb 23 2007 - 20:04:26 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC