One more voice on "linear update" and "!"
Dan Bornstein
(12 Aug 1999 20:02 UTC)
|
One more vote on "linear update" and "!" shivers@xxxxxx (13 Aug 1999 23:53 UTC)
|
One more vote on "linear update" and "!" shivers@xxxxxx 13 Aug 1999 23:53 UTC
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