[R6RS] Re: Zapping SET-CAR! & SET-CDR!
Michael Sperber
sperber
Wed Oct 20 10:53:07 EDT 2004
>>>>> "RK" == Richard Kelsey <kelsey at s48.org> writes:
RK> From: Michael Sperber <sperber at informatik.uni-tuebingen.de>
RK> Date: Mon, 18 Oct 2004 19:36:42 +0200
RK> But these could be done with 2-element vectors as well. If you're
RK> concerned about conciseness, you could do
RK> (define (kons x y) (vector x y))
RK> (define (kar x) (vector-ref x 0))
RK> (define (kdr x) (vector-ref x 1))
RK> (define (set-kar! x v) (vector-set! x 0 v))
RK> (define (set-kdr! x v) (vector-set! x 1 v))
RK> And klist, kappend, kmemq, and so on (KDE Scheme!). I am sympathetic
RK> to wanting immutable pairs, but I think it is too big change. Too many
RK> programs would break.
It seems we still haven't found a consistent interpretation of our
initial statement that we won't worry about backward compatibility so
much. I would be much less favorably inclined towards this change if
a majority at the Scheme workshop hadn't expressed they approved it.
RK> There are algorithms that operate much more efficiently on mutable
RK> lists. Some programs would win and some would lose because of
RK> either using slower algorithms on immutable lists or by the added
RK> cost of converting back and forth between the two types.
So, would an alternative be to make mutability more explicit in the
standard? Either by having something like MAKE-IMMUTABLE!, which
works on any kind of non-closure heap object, or by having
IMMUTABLE-CONS and so on. Then we could have argument lists be
immutable and at least reap some of the benefits.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
More information about the R6RS
mailing list