You guys just love messing with my life, don't you? Enough of this
last-minute, stay-of-execution, midnight-phone-call-from-the-governor
stuff. Throw the switch and let's fry this thing.

   From: Dan Bornstein <xxxxxx@milk.com>
   Date: Thu, 12 Aug 1999 13:02:39 -0700 (PDT)

   I've been thinking a lot about the whole linear update issue, and I agree
   that having a way to advise the system about object use without forcing a
   particular paradigm (destructive or not) is a good thing. However, the
   simple fact is that the pre-existing meaning of "!" in Scheme is *not*
   linear update--it is destructive modification--as most obviously
   demonstrated by these procedures:

       set!
       set-car!
       set-cdr!

   What would each of these mean if they were linear update anyway? They all
   return unspecified values, for one thing, so if they were recast in a
   linear update light, that would have to change. But let's say that you did
   that, then there are still problems. For example, set-cdr! is often used to
   create circular lists, but if it were defined to be nondestructive in a
   particular implementation, there would be no way to do this.

No, no. SET-CAR! and SET-CDR! are undoubtedly non-linear, guaranteed
side-effecting procedures. I do not mean to imply otherwise.

Here's my take on the linear list procedures. REVERSE!, APPEND! and friends
have been around for a while, even though they aren't RnRS. These procedures
have *always* had to be used in a "linear" fashion, even before I came along
and did list-lib -- because of the empty list.

That is, you cannot, *in general,* rely on this working:
     (begin (append! foo bar)
            foo) ; Use FOO non-linearly -- is now a longer list
The problem is that FOO might be bound to (). Then APPEND has nothing to
SET-CDR!; it just returns BAR.

All the side-effecting list procedures have this property. If you provide a
guaranteed side-effecting list procedure, in general you must use it in in a
linear fashion (note I said "in general" -- if you can guarantee that the list
argument is non-empty, then you can get around this). In other words, you
*can't* provide a guaranteed side-effecting list procedure, really, because
*not all lists can be side-effected.*

I would have used another convention if I'd been able to think one up.
But neither I nor anyone else had a really good idea. I suppose I could
have used a "1" suffix (e.g., APPEND1, REVERSE1) for "linear," but that
is obscure and seems ugly to me.

Very well. Let us take one more vote. Would people like to see the linear
update procs renamed to
   take1
   drop-right1
   append1
   append-reverse1
   append-map1
   map1
   filter1
   partition1
   remove1
   delete1
   delete-duplicates1
   alist-delete1
   reverse1
   lset-union1
   lset-intersection1
   lset-difference1
   lset-xor1
   lset-diff+intersection1

I am *not* going to provide procedures that are guaranteed-side-effecting-
when-possible-otherwise-functional. Ech. I *will* consider renaming these
procedures. But this 1-suffix convention is pretty ugly, and you are going to
see it again and again in the SRFI's I am getting ready to propose for
vectors, character sets, strings, sorting, etc.
     -Olin