Re: [Chicken-users] Question about set-car! and set-cdr!

[Ivan Shmakov]

>>>>> Daniel Carrera <address@hidden> writes:
>>>>> Jörg F. Wittenberger <address@hidden> wrote:
>>>>> Am 06.03.2014 09:05, schrieb Daniel Carrera:

 >>> I have recently learned about set-car! and set-cdr! which
 >>> eventually led me to learn about how Racket removed them years ago
 >>> for the reasons given in this post:

 >>> http://blog.racket-lang.org/2007/11/getting-rid-of-set-car-and-set-cdr.html

 >>> On the other hand, Chicken certainly has set-car! and set-cdr! and
 >>> I also see these functions in R7RS.  I was wondering if there is a
 >>> balancing opinion (maybe a post somewhere) on this matter.

 >> Frankly I find the above posting pretty balanced.  Most people agree
 >> that pure functional code is easier to judge and get right than code
 >> having mutation.

[…]

 >> Maybe this could be addressed by splitting the "scheme" module of
 >> chicken into a "scheme-pure" for the sake of safety,
 >> "scheme-mutations" having the rest and make "scheme" importing and
 >> reexporting both sets of bindings.

        That’s what the Racket folks did: they have their own Scheme
        dialect without mutable pairs, and they have the “standard”
        Scheme(s) available as an option.

 > Yeah.  I have to admit that I found the argument in the post
 > persuasive.  Racket's promise of safety is enticing.  But I wondered
 > if there was a reason why the rest of the Scheme world hasn't rushed
 > to adopt this seemingly great idea.  I suppose that it could be a
 > matter of history, as you suggest.

        Somehow, I believe that there’s no /immediate/ benefit from
        getting rid of mutable pairs, at least not beyond that which
        could already be achieved by simply not using these while
        writing one’s own code.  OTOH, there /is/ an immediate burden on
        implementors of implementing the change, documenting it, and
        maintaining now /two/ distinct languages – one “standard”, and
        one “functional”.

-- 
FSF associate member #7257