Immutable things.

[Henry G. Baker]

> I think all this talk of deciding which functions do and don't return
> immutable things is foolish. What are you going to do? Have a
> map-car-immutable which returns an immutable list and map-car-mutable
> which returns a mutable one? Are you going to double up on every
> function in Scheme or CL?

mapcar could easily be polymorphic -- if it is given a mutable list, it
returns a mutable list, while if it is given an immutable list, it returns
an immutable list.

Pray tell; exactly how many times do you want mapcar to return a
mutable list under _any_ conditions?

> If you must have immutable things I encourage some function which
> makes an existing object immutable, possibly recursively through
> structures.

In some sense, you are doing this already, since mapcar only cares
about the _values_ of the list, and not upon the list itself.  So
(mapcar f (coerce-to-functional l)) = (mapcar f l)

By forcing functionality of the input list, you are eliminating all
that uncertainty that currently exists about what shares with what
else, and some of the order-of-computation issues.

I'd be very interested in how many times in high quality Lisp
programming mutable lists are _ever_ used.  (Besides my 'Shallow
Binding' paper ;-) The 'Reduce' people told me that they initially
used rplaca/d all over the place, and were pleasantly surprised that,
when they got rid of them in order to make the system more
maintainable, it actually got _faster_, as well, although that wasn't
the goal of the project.

-- 
Henry Baker
www/ftp directory URL:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html