[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
One more vote on "linear update" and "!"
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 <danfuzz@xxxxxxxx>
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:
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
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.