[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